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NATIONAL  INSTITUTE  OF  STANDARDS  AND  TECHNOLOGY 

INTERNAL  REPORT 

COMPUTER  SECURITY:  SELECTED  ARTICLES 

INTRODUCTION 


This  National  Institute  of  Standards  and  Technology  Internal  Report  (NISTIR)  presents  nine 
articles  which  represent  a wide  spectrum  of  computer  security  information.  The  articles 
were  selected  by  the  staff  of  the  Computer  Security  Division,  Computer  Systems 
Laboratory,  at  the  National  Institute  of  Standards  and  Technology.  The  information 
provided  is  by  no  means  comprehensive;  rather  the  articles  offer  a quick  reference  or  an 
introduction  to  a specific  security  technology.  The  article  "Is  your  System  Safe?"  is  a 
high-level  overview  of  the  Internet  worm  and  addresses  ways  to  correct  various  system 
vulnerabilities.  The  article  "Computer  Viruses  and  Personal  Computers"  provides  guidance 
on  preventing  and  handling  computer  viruses.  The  remaining  articles  discuss  software 
copying,  local- area- network  security,  computer  ethics,  data  security  responsibilities,  risk 
analysis,  and  encryption.  This  publication  will  benefit  computer  security  managers  as  well 
as  managers  and  users  of  information  technology. 

The  second  part  of  this  document  contains  a reading  list  prepared  by  the  Information 
Exchange  Working  Group  of  the  Computer  and  Telecommunications  Security  Council,  a 
govemment/industry  technical  group  that  was  sponsored  by  NIST  from  1987  to  1990.  The 
list  provides  titles,  sources,  and  abstracts  of  important  computer  security  publications  that 
were  relevant  to  the  council’s  interests. 

The  National  Institute  of  Standards  and  Technology  (NIST)  makes  no  claim  or  endorsement 
of  the  information  provided.  However,  as  this  material  may  be  of  use  to  other 
organizations,  NIST  is  reprinting  the  articles  with  permission  as  part  of  a continuing  effort 
to  assist  federal  agencies  in  accordance  with  NIST’s  mandate  under  the  Computer  Security 
Act  of  1987. 

Questions  regarding  this  publication  should  be  addressed  to  National  Institute  of  Standards 
and  Technology,  Computer  Security  Resource  Center,  A-216  Technology,  Gaithersburg,  MD 
20899.  Additional  copies  of  this  publication  may  be  purchased  through  the  National 
Technical  Information  Service,  Springfield,  VA  22161,  telephone:  (703)  487-4650. 
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IS  YOUR 
SYSTEM 
SAFE? 


worm  brought  the  Internet 
to  its  knees , the  danger 
to  UNIX  networks 


still  exists 


By  Frank  Hayes 


l • - arly  this  year,  Cornell  University  graduate  student 

i Robert  T.  Morris  was  convicted  of  creating  a rogue 

fT' 

computer  program  — a “worm”  — and  releasing  it  into 
the  Internet.  When  this  issue  of  UNIXWORLD  went  to  press, 
Morris  was  still  awaiting  sentencing.  But  the  evidence  that 
convicted  Morris  brought  home  the  stunning  impact  of  the 
Internet’s  collapse. 

In  all,  the  worm  temporarily  disabled  as  many  as  3000  ma- 
chines on  the  network,  which  links  UNIX- based  computers 
at  universities,  businesses,  and  military  research  facilities. 
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PC  Viruses,  UNIX  Worms 


It  took  days  of  intensive  work  (8000 
personnel  hours,  by  one  estimate)  to 
isolate  the  worm  and  clear  it  from  the 
Internet.  No  data  was  destroyed,  but 
realistic  estimates  of  time  lost  on  the 
affected  machines  range  as  high  as  $10 
million. 

And,  astonishingly,  more  than  a year 
later  some  of  the  bugs  that  Morris’ 
worm  program  exploited  still  threaten 
UNIX  users. 

Could  It  Happen  Again? 

The  Internet  worm  used  three  major 
means  of  attack.  Two  involved  flaws 
in  the  mail  system  of  Berkeley  exten- 
sions to  UNIX:  a problem  in  the 
sendmail  program,  and  another  in 
f ingerd.  The  third  was  a password- 
guessing routine  that  gave  the  worm 

It  took  days  of  intensive 
work  (8000  personnel 
hours,  by  one  estimate) 
to  isolate  the  worm 
and  clear  it  from  the 
Internet. 

access  to  other  Berkeley  system  utili- 
ties it  used  to  propagate  itself.  Because 
it  depended  on  these  flaws,  the  worm 
only  succeeded  in  infecting  computers 
running  Berkeley  versions  of  UNIX 
and  its  derivatives.  It  was  also  limited 
to  certain  kinds  of  hardware  — DEC 
VAXes  running  BSD  UNIX,  and  some 
Sun  workstations.  (See  Editor-at- 
Large  Rik  Farrow’s  article  describing 
how  the  worm  did  its  work.) 

Quick  fixes  for  the  problems  with 
sendmail  and  fingerd  became 
available  almost  immediately  after  the 
worm  incident  from  the  teams  of  pro- 
grammers at  Berkeley  and  MIT  who 
disassembled  the  worm.  And  new  ver- 
sions of  the  software  have  since  been 
released  by  the  vendors,  plugging  the 
security  holes. 

But  according  to  UNIX  security  ex- 
perts we  talked  to,  some  systems  on 
the  Internet  still  haven’t  upgraded 
their  software  — and  far  more  non- 
Internet  systems  still  have  the  old  ver- 
sions of  these  programs. 

That’s  a serious  problem,  according 
to  Beverly  Ulbrich,  Sun  Microsystems’ 


A worm  is  a standalone  computer 

program  that  reproduces  itself.  That’s 
in  contrast  to  a virus,  which  is  a program 
section  that  can  copy  itself  onto  other 
programs.  Viruses  are  a widespread 
problem  on  desktop  microcomputers, 
including  IBM  PC-compatibles  and  Apple 
Macintoshes.  Virus  programs  on  these 
PCs  are  notorious  for  corrupting  data, 
erasing  files,  and  reformatting  hard  disks. 
By  contrast,  the  Internet  worm— the  most 
devastating  worm  program  to  hit  the  UNIX 
community— merely  wasted  thousands  of 
hours  of  computer  time. 

Why  do  viruses  strike  PCs,  while  worms 
hit  UNIX  networks?  PC  viruses  are  typically 
spread  on  floppy  disks;  when  an  infected 
program  on  the  disk  is  run,  the  virus  copies 
itself  onto  programs  on  other  floppy  or 
hard  disks.  Viruses  are  common  on  PCs 
because  of  the  standardized  hardware 
(which  allows  virus  code  to  run  without 
recompilation),  and  because  virtually  all 
PCs  use  floppy  disks  as  their  primary  way 
of  getting  software  into  the  computer. 

UNIX  machines  as  a group  share  neither 
of  these  risks— but  UNIX  networks  allow 
different  avenues  of  attack.  For  example, 
the  highly  developed  mail  system  that  links 


product  manager  for  SunOS  security. 
Forcing  users  to  upgrade  their  soft- 
ware is  impossible.  “Obviously,  the 
most  we  can  do  is  make  people  aware 
of  the  probleml'  Ulbrich  says.  The 
sendmail  problem  is  a case  in  point. 
Sun  distributed  a fixed  version  a year 
ago,  but  Ulbrich  says  bug  reports  con- 
tinue to  arrive  at  Sun  — complaining 
about  security  problems  with  the  old 
version.  “It’s  one  of  the  biggest  frus- 
trations we’ve  got!’  she  says. 

Hoping  to  change  the  situation, 
Ulbrich  says,  Sun  is  currently  devel- 
oping a program  to  streamline  the  pro- 
cess of  converting  bug  reports  into  cor- 
rected software  that’s  actually  on 
users’  machines.  But  it’s  not  as  simple 
as  sending  mailgrams  to  every  Sun 
owner.  “When  we  hear  about  a prob- 
lem, we  can’t  just  immediately  publi- 
cize it.  We  have  to  make  sure  we  have 
a workaround  or  new  binaries!’  says 
Ulbrich. 

Then  there’s  the  problem  of  distrib- 
uting the  fixes  once  they’re  available. 
Ulbrich  says  Sun  is  considering  dial-up 
machines,  as  well  as  backup  telephone 
and  fax  systems  that  could  be  used 
when  a rampaging  worm  has  forced 
system  administrators  to  disconnect 
their  computers  from  the  outside 


many  UNIX  systems  allows  unscreened 
messages  to  enter  your  system— and,  in 
some  cases,  unscreened  program  code. 
The  Internet  worm  exploited  a common 
bug  in  the  sendmail  utility  that 
allowed  a program  to  be  sent  as  a 
message,  then  compiled  and  executed 
on  the  system  that  received  it. 

In  addition,  most  PCs  can  only  run 
one  program  at  a time— so  to  be 
executed,  the  virus  code  must  link 
itself  to  an  application  someone  is 
likely  to  use.  But  multitasking  UNIX 
systems  allow  worms  to  make  copies  of 
themselves  that  run  independently— 
and  without  any  legitimate  user’s 
knowledge. 

As  a result,  while  PCs  are  at  risk 
from  relatively  passive  viruses  that 
are  carried  from  one  computer  to 
another  on  floppy  disks,  UNIX 
machines  are  more  likely  to  be 
attacked  by  worms  that  actively  mail 
themselves  to  other  computers, 
attempt  to  guess  passwords,  and 
reproduce  themselves  as  widely  as 
possible. 

~P.H. 


world.  Sun  hopes  to  have  a pilot  sys- 
tem in  place  this  summer,  she  adds. 

Mail  Call 

Even  when  users  know  new  versions 
are  available,  they're  sometimes  reluc- 
tant to  install  them  — especially  if  the 
users  have  changed  the  program  at  the 
source-code  level  to  add  new  features. 
Ulbrich  isn’t  convinced  that’s  a real 
reason  for  not  upgrading:  “It’s  a real 

According  to  UNIX 
security  experts,  some 
systems  on  the  Internet 
still  haven’t  upgraded 
their  software. 


excuse  that  I’ve  heard!’  she  says.  But 
at  least  some  users  disagree. 

Peter  G.  Neumann,  a computer  sci- 
entist at  SRI  International  who  also 
moderates  an  on-line  network  confer- 
ence on  computer  risks  to  society,  says 
he  isn’t  happy  with  the  version  of 
sendmail  he’s  got  — but  he  doesn't 
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want  to  upgrade  to  a new  “safe”  ver- 
sion because  it  lacks  some  of  the 
functionality  he  needs. 

Nor  does  Neumann  believe  a new 
version  of  the  program  will  really  be 
secure  from  attack.  “You  have  to  re- 
member, the  problems  in  sendmail 
have  been  in  there  forever!’  says 
Neumann.  The  Internet  worm  de- 
pended on  sendmail  having  been 
compiled  with  the  debugging  option  in- 
cluded, but,  says  Neumann,  “It’s  not 
just  the  debug  option.  It  used  to  be 
that  anybody  could  connect  to  it  and 
gain  superuser  status.” 

Part  of  the  problem,  Neumann  ex- 
plains, is  that  UNIX  was  designed 
not  only  with  little  concern  for  secu- 
rity, but  originally,  with  little  con- 
cern for  mail,  either.  “In  1965  there 
was  a solution  to  the  sendmail  prob- 
lem in  Multics!’  he  says.  In  Multics, 
the  mail  system  could  only  append 
mail  messages  to  the  mailbox  — it 
couldn’t  read  files  or  have  any  other 
access  to  the  system.  But  when  Ken 
Thompson  created  UNIX  as  a scaled- 
down  version  of  Multics,  he  didn’t  in- 

Reminding  users  about 
upgraded  vendor  soft- 
ware can  be  handled  with 
e-mail  bulletins. 


elude  the  Multics  mail  system  because 
he  didn’t  need  mail  — UNIX  was  to  be 
a single-user  system.  When  mail  was 
later  added  in  the  Berkeley  extensions 
to  UNIX,  the  implementers  used 
superuser  — the  source  of  most  of  the 
sendmail  security  problems. 

"Think  about  what  you’re  trying  to 
do!’  says  Neumann.  Getting  what  he 
describes  as  “good  solutions  with  a lit- 
tle bit  of  robustness  to  them”  requires 
intelligent  management  and  coopera- 
tion among  all  the  users  of  the  many 
UNIX  mail  networks  — and  it  will  still 
only  work  within  reasonable  require- 
ments. “If  you  want  a wide  open  ex- 
change between  everyone  in  the 
world,  it's  a problem.  It's  a very  diffi- 
cult problem!’  says  Neumann. 

The  Password  Problem 

But  at  least  as  much  of  a problem  as 
buggy  utilities  is  poor  passwords.  The 
Internet  worm  included  a password - 


UNIX  Self-Defense 


Can  your  system  be  infiltrated?  You 
can  cut  down  the  risks  dramatically 
by  tightening  your  policies  in  just  two 
areas:  passwords  and  software  updates. 

Easy-to-guess  passwords  are  the 
biggest  problems  on  most  systems.  Watch 
out  for: 

■ A password  that  matches  the  account 
name. 

■ A password  of  "password,"  “passwd," 
or  no  password  at  all. 

■ The  same  password  used  on  many 
different  machines. 

■ Easily  guessed  passwords  such  as 
common  names. 

To  cut  password  risks,  you  should: 

■ Use  automated  checks  for  bad 
passwords. 

■ Keep  password  files  from  being 
readable  by  users. 

■ Regularly  purge  dormant  accounts, 
which  frequently  have  simple  passwords. 

■ Make  sure  your  users  know  the 
importance  of  choosing  a good  password 
and  keeping  it  secret— and  how  to  change 
the  password. 


■ Discourage  users  from  leaving  for 
the  day  without  logging  off 

Software  updates  will  continue  to  be  a 
problem,  although  more  standardized 
versions,  such  as  System  V Release  4, 
may  help.  In  the  meantime- 

b Check  regularly  with  software 
suppliers  for  updates  and  bug  fixes. 

* If  your  staff  has  modified  utilities, 
document  the  modifications  as  completely 
as  possible. 

■ Make  bug  fixes— especially  for 
security  bugs— a priority. 

Most  of  all,  beware  of  the  common 
attitude  that  security  precautions  on  UNIX 
systems  are  a waste  of  time.  Open 
systems  don’t  have  to  be  open  to  attack 


-F.H. 


guessing  routine  that  allowed  it  to 
worm  its  way  onto  at  least  some  ma- 
chines. And  in  general,  passwords  are 
the  system  of  choice  for  humans  trying 
to  break  into  computers,  UNIX-based 
or  otherwise. 

The  Computer  Emergency  Re- 
sponse Team  (CERT)  was  set  up 
shortly  after  the  Internet  worm  inci- 
dent to  monitor  problems  that  could 
threaten  the  network.  The  CERT  Co- 
ordination Center,  at  Camegie-Mellon 
University’s  Software  Engineering  In- 
stitute in  Pittsburgh,  collects  reports 
of  computerized  break-ins  and  other 
security  problems  from  users,  and  reg- 
ularly issues  advisories  to  system 
administrators. 

Are  things  more  secure  since  the 
worm  attack?  “They're  better,  yes,  in 
the  sense  of  knowing  what  kinds  of 
activities  are  going  on!'  says  Terry 
McGillen.  a spokesman  for  CERT.  But 
though  CERT  keeps  better  tabs  on  se- 
curity problems  today  (it  runs  a 
24-hour  hotline  at  412-268-7090),  the 
actual  number  of  break-ins  seems  to 
be  rising. 

According  to  McGillen,  there  are 
two  major  sources  of  problems:  break- 
ins  that  guess  passwords  and  those 
that  exploit  hoies  in  vendors’  software. 
Reminding  users  about  upgraded  ven- 
dor software  can  be  handled  with 


e-mail  bulletins;  improving  passwords 
is  the  tougher  problem  to  deal  with. 
"People  know  they  shouldn't  do  this, 
but  they’ve  got  too  many  things  to  re- 
member!' says  McGillen,  "so  they  use 
their  zodiac  sign,  or  their  birthdate.  or 
their  social  security  number  as  a pass- 
word!' Worse  still,  users  will  some- 
times put  that  same  easy-to-remember 
password  on  all  their  computer  ac- 
counts. 

Just  Your  Ordinary  Joe 

Russell  Brand,  a former  government 
computer  security  expert,  believes 
password  security  is  so  lax  on  most 
systems  that  even  moderate  work  to 
tighten  things  up  will  discourage  most 
hackers.  In  a primer  he's  developing 
on  dealing  with  computer  security 
problems.  Brand  points  out  that  the 
most  common  case  of  a poor  password 
is  what  he  calls  the  "Joe!'  an  account 
where  the  password  is  the  same  as  the 
user  name. 

Making  the  user  name  the  password 
makes  the  password  easy  to  remem- 
ber—and  exceptionally  easy  to  guess. 
Brand  says  he  has  never  found  a sys- 
tem that  didn't  have  at  least  one  Joe. 
Last  summer,  he  says,  “While  I was 
testing  a series  of  sensitive  systems 
where  hundreds  of  thousands  of  dol- 
lars were  spent  to  remove  security 
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How  the  Worm  Turned 


holes,  including  rewriting  a fair  frac- 
tion of  the  operating  system,  there 
were  Joes!’ 

There  are  simple  ways  to  check  for 
Joes  and  other  bad  passwords,  and  to 
encourage  users  to  pick  (and  protect) 
their  passwords  more  carefully.  Unfor- 
tunately, says  Brand,  many  system  ad- 
ministrators simply  believe  that  sys- 
tem security  is  a waste  of  time. 

Sun’s  Beverly  Ulbrich  sees  the  same 
attitude.  Some  companies,  she  says, 
“don’t  care  at  all.  But  it  gets  important 
as  soon  as  people  get  hit  with  a prob- 
lem. Somebody  guesses  a password  or 
finds  a guest  account,  and  the  system 
gets  broken  into... and  then  they 
panic” 

There  are  simple  ways  to 
check  for  bad  passwords, 
and  to  encourage  users 
to  pick  (and  protect) 
their  passwords  more 
carefully. 

Some  system  administrators  do 
seem  to  take  a casual  attitude  toward 
security.  Scott  Todd,  system  adminis- 
trator at  Cadre  Technologies  in  Bea- 
verton, Ore.,  has  never  had  a break-in. 
He  admits  that  "1  probably  run  the 
least  secure  network  of  any  of  the  sys- 
tem administrators  I know!’  and  says 
of  security  procedures,  “they  waste 
time  and  they  waste  other  people’s 
time!’  But  Todd  carefully  screens  new 
software  that’s  introduced  into  his  net- 
work of  40  Sun  workstations,  and  be- 
cause his  network  is  only  a mail  site, 
he  knows  he's  protected  from  attacks 
such  as  the  Internet  worm.  And  though 
he  takes  no  special  precautions  for 
password  security,  he  says,  “We’re  a 
small  site;  as  we  get  bigger  I may  have 
to  pay  more  attention  to  that.” 

Another  system  administrator,  who 
asked  not  to  be  named,  is  currently 
building  a much  larger  UNIX  system 
at  a major  financial  services  company, 
and  he’s  substantially  more  concerned 
with  security.  Like  Todd,  this  adminis- 
trator says:  “Internet  is  not  an  issue 
with  us.  This  is  going  to  be  a commer- 
cial network,  so  ours  is  going  to  be 
pretty  tightly  wrapped!’ 


On  Wednesday  night,  November  2, 
1988,  Cornell  graduate  student 
Robert  T.  Morris  released  his  worm  into  the 
Internet.  The  worm  was  intended  to  spread 
itself  quietly  throughout  the  network  by 
guessing  passwords  and  exploiting  bugs 
in  e-mail  and  other  networking  utilities. 

But  the  program’s  explosive  growth— 
and  the  reactions  of  baffled  system 
administrators  trying  to  protect  their 
systems— virtually  shut  down  the  network 
for  two  days. 

The  worm  was  first  introduced  into  a 
VAX  11/750  at  the  MIT  Artificial  Intelligence 
Laboratory  at  about  8 p.m.  (EST)  on 
Wednesday  night.  Within  an  hour  it  had 
spread  across  the  country  through  the 
Internet  e-mail  system.  At  6:24  p.m.  (PST)  it 
infected  a computer  at  the  Rand  Corp.  in 
Santa  Monica,  Calif.  At  7:04  p.m.  (PST),  it 
infected  a major  network  gateway  at  the 
University  of  California  at  Berkeley  Fifty 
minutes  later,  the  worm  reached  machines 
at  the  University  of  Maryland  and  Cornell 
University,  and  less  than  an  hour  after  that 
it  had  attacked  virtually  every  susceptible 
machine  on  the  Internet. 

The  worm  also  made  multiple  copies  of 
itself  in  every  computer  it  infected— so 
many  copies  that  eventually  work  on  each 
infected  computer  ground  to  a halt,  as 
the  machines  spent  most  of  their  time 
executing  copies  of  the  worm  program. 

At  the  University  of  Utah,  the  VAX  8600 
that  serves  as  the  central  machine  for 
the  computer  science  department  was 
infected  at  9 49  p m (MST)  By  10  06  p.m. 
the  multiplying  worms  had  rendered  the 
system  completely  unusable.  At  10:20. 
system  programmer  Jeff  Forys  cleared  the 
system  of  worms,  by  10  41  it  had  become 
unusable  again.  At  10  49,  Forys  shut  down 
the  computer  entirely,  then  restarted  it 
At  11:21,  the  computer  was  once  again 
useless  because  of  re-infestation  In  spite 
of  continuous  efforts  to  kill  the  worms, 
nothing— including  bringing  down  the 
entire  system-seemed  to  stop  them 
Because  the  Internet  connects  university 
and  private  researchers  with  military  and 
other  government  computers,  the  worm 
quickly  spread  to  sites  where  highly 
classified  work  is  done,  including 
Lawrence  Livermore  National  Laboratories. 
NASA's  Ames  Research  Center,  and  the 
Army  Ballistic  Research  Laboratory  at 
Aberdeen  Proving  Ground.  Md 

At  the  Ballistic  Research  Laboratory, 
staffers  initially  assumed  that  the  worm 
was  an  attack  on  its  systems  by  foreign 


A bigger  concern  is  modems  that 
will  connect  the  six  to  eight  file  serv- 
ers and  hundreds  of  PC  workstations 
across  the  country:  “The  modem  is  our 


intelligence  agents  Michael  Muuss.  who 
leads  the  Aberdeen  computer  systems 
team,  later  testified:  “We  have  a history 
of  foreign  intelligence  activity  on  our 
systems,  and  foreign  nations  take  a great 
deal  of  interest  in  the  activities  of  our 
research  scientists."  The  weapons  lab 
disconnected  itself  from  the  network  for 
six  days  to  make  certain  that  no  data  had 
been  destroyed  or  modified. 

As  it  became  clear  that  the  worms  were 
using  the  Internet  to  spread,  some  sites 
“quarantined"  their  systems,  cutting  off  all 
connection  to  the  network.  The  result: 
though  those  systems  may  have  been 
protected,  the  quarantine  attempts 
crippled  the  ability  of  the  network  to 
send  e-mail— including  messages  about 
how  to  combat  the  worms. 

In  the  early  hours  of  the  following 
morning,  as  teams  across  the  country 
worked  on  solutions  to  the  worm  infestation, 
an  anonymous  e-mail  message  was  sent 
through  the  network  The  message  came 
from  Andrew  Sudduth,  a systems  manager 
at  Harvard  University’s  Aiken  Computation 
Lab  and  a friend  of  the  worm  s author; 
it  included  instructions  for  preventing 
further  spread  of  the  worm  But  though  the 
e-mail  message  was  addressed  to  virtually 
all  systems  on  the  network,  it  was  blocked 
for  almost  two  days  by  a quarantined 
computer  Other  messages  from  teams 
combatting  the  worm  were  also  delayed  by 
the  crippled  mail  system. 

Although  the  worm  was  isolated  and  the 
network  cleared  within  days,  the  collapse 
of  the  Internet  stunned  users  and  system 
administrators  alike  It  was  the  most 
graphic  in  a recent  string  of  incidents 
demonstrating  how  vulnerable  UNIX 
systems  are  to  software  sabotage 

In  all.  as  many  as  3000  computers  were 
temporarily  disabled  by  the  worm,  at 
locations  ranging  from  universities  to 
military  research  labs  to  the  National 
Cancer  Institute  The  New  York  Times 
reported  that  at  Carnegie-Mellon 
University  in  Pittsburgh,  80  of  100 
computers  were  affected,  at  the  University 
of  Wisconsin,  200  of  300  machines  were 
hit  Though  no  data  was  destroyed 
one  industry  association  estimated  total 
damage  in  lost  work  at  nearly  $100  million 
More  realistic  estimates  place  the  cost  as 
high  as  $10  million 


first  line  of  defense.  If  it’s  off.  it's  off! 
he  says.  And  password  security  will 
be  backed  up  by  physical  security  for 
the  computer  sites,  which  will  be 
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IS  YOUR  SYSTEM  SAFE? 


tightly  controlled.  But  he  admits  that 
for  his  company,  this  is  new  ground: 
“We’re  traditionally  a large  IBM  shop, 
and  I mean  large.  But  UNIX  is  begin- 
ning to  come  in  a lot  of  places!'  he  says, 
and  without  the  built-in  security  that 


IBM  provides,  protecting  the  network 
is  a challenge. 

Open  Systems,  Open  Doors? 

Is  your  system  safe?  Or  can  you  only 
protect  it  from  worms  and  viruses  by 


The  CERT  Coordin- 
ation Center  hotline, 
k staffed  24  hours  a 

: - day,  handies  reports 

? of  network  break- 

ins.  The  hotline’s 
number  is  412- 
268-7090. 

Russell  Brand’s 
primer  on  computer 
security  at  network 
sites,  which  covers 
topics  ranging  from 
prevention  to  deal- 
ing with  the  after- 
math  of  a break-in, 
is  available  free  in 
electronic  form  or 
for  $10  in  printed 
form  in  the  United 
States,  Contact 
Russel!  Brand,  1862 
Euclid  Ave.,  Berk- 
eley, CA  94709. 


disconnecting  it  from  all  network?  and 
phone  line?,  and  carefully  guarding  it 
against  all  outsider? v 

A?  Dennis  Ritchie  pointed  out  more 
than  10  years  ago:  "UNIX  was  not  de- 
veloped with  security,  in  any  realistic 
sense,  in  mind:  this  fact  alone  guaran- 
tees a vast  number  of  holes!'  However, 
there  are  steps  you  car.  take  to  protect 
against  the  most  common  sources  of 
invasion  ■ see  the  “UNIX  Self  Defense" 
sidebar  i 

And  although  security  shouldn’t  be- 
come a full-time  preoccupation  for  sys- 
tem administrators,  in  the  year  since 
the  Internet  worm  it  has  become  a 
major  concern  for  almost  every  net- 
worked computer  system  — and  that 
means  nearly  every  UNIX  system. 
Robert  T.  Morris  has  been  caught  and 
convicted  — but  the  holes  and  bugs  the 
worm  highlighted  may  be  the  quarry 
of  a hunt  that  will  last  for  years  to 
come.  G 


Features  Writer  Frank  Hayes  has  covered 
the  computer  industiy  for  seven  years. 
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Proper  assignment  of 
responsibility  for  data 

security 


Robert  H Courtney,  Jr  suggests  that  the  primary  responsibility'  for  data 
security  should  rest  with  the  user  community 

Reprinted,  with  permission,  from  the  February  1988  issue.  Volume  7 #1 
f Computers  & Security.  Elsevier  Advanced  Technology,  Mayfield  House,  256  Banbury  Road, 

Oxford  0X2  7DH 


An  analysis  of  the  data  securin'  responsibilities  within  an 
organization  is  presented.  It  is  proposed  that  DP  manage- 
ment should  not  have  total  responsibility,  but  that  this 
should  be  shared  by  sta  ff  in  the  functional  areas  to  ensure 
cost-effectiveness  and  viability  By  assessing  organization 
structure  and  data  integrity,  a clearer  picture  emerges  of  the 
roles  and  responsibilities  of  individual  staff  members. 

Keywords:  data  security,  cost-effectiveness,  data  integrity, 
organization  structure 


Data  processing  management  should  not  have  primary 
responsibility  for  data  security.  Although  adequate 
data  security  often  depends,  at  least  in  part,  on  controls 
which  must  be  implemented  and  maintained  by  the 
DP  stall,  identification  of  the  need  for  most  secunrv 
controls  and  their  cost-justification  should  be  the 
responsibility  of  other  people  who  are  in  better 
positions  to  do  them  than  are  the  DP  stall.  These 
assertions  are  derived  from  our  frequent  opportunities 
to  observe  in  operation  each  of  several  pertinent 
factors. 

• Security  is  a people  problem.  Most  of  the  losses 
attributable  to  computer-related  data  security 
problems  are  contributed  by  people  in  the  functional 
areas  supported  by  the  DP  organization  and  who 
are  not  on  the  DP  staff.  These  people  are  best 
controlled  by  their  immediate  management  and  not 
by  the  data  processing  organization. 

River  Roud.  Port  Ewen.  New  York  12466.  USA 


• Most  DP  directors  have  little  opportunity  for  first- 
hand knowledge  of  the  real  consequences  to  the 
organization  of  accidental  or  intentional  modifi- 
cation. disclosure,  destruction,  or  delay  of  the  data 
on  which  the  functional  areas  of  the  business  are 
dependent.  Thus,  the  DP  management  is  in  a much 
poorer  position  than  the  functional  area  manage- 
ment to  assess  the  cost-benefit  relationships  needed 
to  justify  the  implementation  of  appropriate  business 
controls,  including  data  security  measures. 

• DP  directors  are  rarely  measured  in  terms  of  the 
adequacy  of  their  data  security  program.  If  they  have 
primary  responsibility  for  data  security.  the>  will  be 
blamed  for  most  detected  secunrv  lapses  even 
though  they  will  usually  have  had  little  or  no  ability 
to  detect  or  avoid  them.  They  will  not  be  appreciated 
for  their  success  in  providing  secunrv.  Successes  in 
secunrv  are  nonevents.  Secunrv  failures  are  always 
more  readily  recognized  than  are  successes. 

The  greatest  single  bamer  to  the  achievement  of  a 
cost-effective  computer  secuntv  program  is  the  improper 
placement  of  responsibility  for  data  secunrv-  The 
assignment  of  that  responsibility  to  the  DP  area  which 
does  not  have  management  control  over  the  people 
causing  the  problem,  which  is  rareiv  in  a position  to 
recognize  Hawed  data  as  an  indicator  of  a secunrv 
problem,  and  which  is  in  a poor  position  to  assess  the 
consequences  to  the  organization  of  secunrv  lapses  is 
usually  a poor  choice  indeed. 

The  data  processing  management  must  have  pnmarv 
responsibility  for  the  protection  for  the  resources  under 
their  direct  control.  For  example,  only  the  DP  manage- 
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ment  is  in  a position  to  lead  the  development  of 
contingency  plans  for  centralized  data  processing 
facilities.  Because  they  must  take  the  lead  in  contingency 
planning  and  in  assuring  the  physical  safety  of  the 
facilities  under  their  immediate  control,  it  does  not 
follow  that  there  is  supporting  rationale  for  the 
assignment  to  the  DP  area  of  responsibility  for  all  data 
security. 

The  managers  of  the  functional  areas  supported  by 
data  processing  should  have  primary  responsibility  for 
the  security  of  their  respective  data  aggregations.  They 
should  identify  needed  controls  with  the  help  of  those 
with  competence  in  specific  security  areas,  such  as  the 
physical  security  specialists,  the  buildings  and  ground 
staff,  and  the  DP  management,  but  they  should  retain 
responsibility  for  the  security  of  the  data  on  which  their 
functions  depend. 

The  user  manager  should  provide  the  cost-justifi- 
cation for  the  controls  they  need.  Where  at  all  possible, 
particular  security  needs  should  be  charged  back  to  the 
respective  areas  generating  those  costs.  The  high 
security  costs  of  some  areas  should  not  be  a burden  to 
all  users.  Distribution  of  those  costs  to  all  users  without 
regard  to  the  specific  security  needs  of  the  respective 
areas  often  leads  to  a somewhat  exaggerated  specifi- 
cation of  those  needs  by  some  users. 

If  users  must  specify  and  pay  for  security  controls, 
there  is  reasonable  hope  of  achieving  balance  in  the 
overall  approach  to  data  security.  If  they  ask  for  too 
much  security,  it  costs  too  much.  If  they  ask  for  too 
little,  they  risk  losses  attributable  to  them  as  a result  of 
not  having  defined  their  security  needs  adequately. 
Further,  the  internal  audit  function  should  see  that  the 
control  requirements  have  been  defined  by  the  users 
with  adequate  ngor  and  without  neglect  of  important 
securirv  considerations. 


PROBLEM  LOCI  IN  RELATION  TO  THE 
ORGANIZATION  CHART 

Figure  1 depicts  the  relative  sizes  of  the  major 
computer  security  problem  categories1  It  is  apparent 
that  losses  due  to  mistakes  greatly  exceed  the  losses 
attributable  to  the  othercauses.  Further,  the  two  largest 
problem  categories  are  mistakes  and  dishonest 
employees*  which  have  these  important  characteristics 
in  common: 


* While  it  is  fairly  difficult  to  gather  data  on  computer-related  crime, 
it  is  almost  impossible  to  compile  data  on  losses  due  to  mistakes 
through  compilations  and  analyses  of  incident  reports.  Our  data, 
which  indicate  between  fifty  and  eighrv  percent  of  the  security  losses 
attributable  to  mistakes,  result  from  a survey  of  2 500  organizations 
which  were  requested  to  rank  the  loss  categories  and  provide  gross 
relative  quantilications  for  them  We  have  been  more  successful  in 
assessing  the  elfect  ol  controls  on  mistakes  than  we  have  been  in 
measuring  the  total  losses  attributable  to  them.  Nevertheless,  we  are 
quite  confident  that  our  50-X0%  spread  is  great  enough  to  contain  the 
proper  apportionment  of  losses  to  that  cateeorv  tor  most  organizations 


Figure  l.  Computer  security  problem  ranking  as  percent- 
age of  all  DP  security  losses 


• It  is  often  difficult  to  tell  whether  something 
improper  was  done  accidentally  or  intentionally 
that  is.  into  which  of  these  two  categories  a particular 
problem  should  be  placed. 

• The  most  important  controls  are  often  equallv 
applicable  to  both  categories.  Controls  directed 
specifically  at  one  of  these  two  categories  almost 
always  have  a proportionately  equal  effect  on  the 
other.  This  interrelationship  forms  the  basis  for  our 
conviction  that  the  crooks  will  never  win  over  the 
incompetents  in  any  competition  to  see  who  will 
cause  the  greatest  damage  to  data. 

• The  people  contributing  the  greatest  portion  of  the 
losses  attributable  to  these  problems  are  rarely  in 
technical  roles  but  most  commonly,  work  in  the  user 
areas  of  the  organization. 

• Problems  in  both  of  these  categories  are  frequentlv 
neglected  in  favour  of  concern  for  externally 
originating,  more  intellectually  challenging  and 
potentially  less  embarrassing  problem  sources. 
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Figure  2.  Computer-related  employee  theft  as  function  ol 
wage  levels 
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Figure  2 relates  computer-supported  theft  by  employees 
to  their  respective  salary  levels.  As  the  figure  shows, 
slightly  more  than  80%  of  the  theft  by  computer  was 
contributed  by  employees  in  the  fourth  and  fifth  salary 
quintiles,  i.e.  in  the  bottom  40%  of  the  wage  scale.  The 
great  majority  of  these  people  are  clerical  employees  in 
data  entry,  file  maintenance,  and  query  responses 
while  most  of  the  others  are  lower  level  administrative 
and  operational  employees. 

Losses  to  persons  in  the  first  salary  quintile,  the  most 
rapidly  growing  group,  are  in  second  place*.  Even 
though  the  losses  in  this  employee  category  are  growing 
rapidly,  now.  we  estimate,  at  about  18%  per  year,  this 
growth  rate  will  not  be  maintained  and  those  losses  will 
not  approach,  except  in  some  very  unusual  and 
probably  localized  circumstances,  the  losses  to  the 
employees  in  the  lower  40%  of  the  salary  range**. 

The  people  best  equipped  to  mount  the  more 
sophisticated  intrusions  into  the  data  processing 
complexes,  who  are  most  often  described  in  the  general 
and  trade  press  as  posing  a major  security  threat 
because  of  their  technical  strength,  report  to  the  data 
processing  management  and  are  usually  in  the  second 
and  third  salary  quintiles.  Contrary  to  conventional 
wisdom,  these  people  are  responsible  for  only  a very 
small  portion  of  employee  theft  through  misuse  of  the 
data  processing  resources.  To  the  extent  that  we  have 
security  problems  presented  by  the  technically  strong 
employees,  they  usually  do  not  involve  theft  but  more 
commonly  reflect  £ desire  to  do  harm  to  the  organization 
as  a result  of  morale  problems  of  one  type  or  another. 
There  is  a striking  correlation  between  the  amount  of 
damage  done  by  technically  oriented  data  processing 
people  and  the  imminence  of  such  potentially  disruptive 
events  as  mergers,  acquisitions,  and  divestitures,  which 
threaten  the  stability  of  the  current  DP  organization 
This  aspect  of  computer  security,  unlike  the  overall 
data  secuny  problem,  is  best  controlled  by  the  DP 
management  to  whom  those  people  report. 

The  people  contributing  the  major  losses  shown  in 
our  figure  are.  for  the  most  part,  not  on  the  DP  stall: 
they  work  in  the  DP  user  community.  No  control  which 
limits  the  resources  to  which  they  have  access  will  be 
very  effective  in  controlling  their  misconduct  because 
they  abuse  the  resources  to  which  they  must  have 


•These  data  came  from  the  histones  of  1 474  cases  of  computer- 
related  theft  or  malicious  damage  in  the  three  years  ending  August 
31.  1987  We  cannot  know  what  portion  of  the  total  number  of  such 
cases  these  represent,  but  we  do  believe  that  they  constirute  a 
statistically  significant  sample.  .Although  we  have  data  gathered  over 
11  years,  we  do  not  include  those  earlier  data  because  they  are  not 
descnptive  of  today  s operating  environment. 

**For  the  first  several  years  we  gathered  data  on  this  subject  and 
observed  a verv  low  theft  rate  by  people  in  the  highest  salary  quintile. 
We  naiveiv  artnbuted  this  to  the  greater  intcgnry  of  those  more  senior 
people  We  did  not  give  adequate  consideration  to  their  lack  of 
technical  competence  in  our  gathering  of  data  on  computer-related 
crime  That  situation  is  nowchanaing  rapidlv  as  the  number  of  on- 
line PCs  in  the  upper  echelon  offices  continues  to  increase 


access  to  get  their  assigned  work  done.  On  the  other 
hand,  the  problems  that  they  contribute  can  usually  be 
managed  into  submission  by  appropriately  chosen 
combinations  of  personal  identification,  logging,  and  a 
carefully  planned  and  intelligent  processing  of  those 
logs. 


ASSESSING  DATA  INTEGRITY 

The  usefulness  or  relative  value  of  data  are  usually 
heavily  dependent  upon  the  integrity  of  those  data.  But 
the  accuracy  of  this  statement  is,  in  turn,  wholly 
dependent  upon  the  acceptance  of  a definition  of 
integrirv  which  does  not  imply  perfection.  Integrity 
should  not  be  used  to  mean  completely  free  of  flaws,  a 
condition  which  is  usually  unachievable  in  any 
realistic,  cost-effective  DP  environment. 

Whether  we  are  discussing  data,  people,  systems  or 
programs,  we  have  found  it  convenient  to  define 
integrity  as  ‘the  property  of  being  no  worse  than 
thought  to  be'.  A system  does  not  have  to  be  perfect  to 
have  integrity;  it  need  only  be  no  worse  than  we  think  it 
is.  i.e.  free  of  unpleasant  surprises.  We  can  often  do 
good  work  with  some  rather  poor  people,  but  only  if  we 
know  just  how  poor  they  are.  Similarly,  we  often  work 
quite  comfortably  with  data  that  are  far  from  perfect 
provided  only  that  we  know  what  the  limitations  are  on 
the  accuracy,  completeness,  timeliness,  and  privacy  of 
those  data.  It  is  when  the  data  are  worse  than  we  think, 
that  is.  when  their  integrity  is  impaired,  that  we  most 
commonly  encounter  trouble  using  them. 

If  we  need  to  know  the  integrity  of  our  data  for  them 
to  be  fully  useful,  who  is  to  have  the  role  of  assessing 
that  integrity',  of  specifying  the  degree  of  degradation 
that  can  be  tolerated,  and  finally,  of  specifying  the 
controls  necessary  to  the  realization  of  the  needed 
integrity  goals?  The  very  important  answer,  and  the  one 
which  is  fundamental  to  the  notions  presented  here,  is 
that  only  the  management  of  those  functional  areas 
using  those  data  are  ordinarily  in  a position  to  make 
those  determinations,  including  assessments  of  the 
cost-benefit  relationships  between  losses  and  the  cost 
of  the  controls  necessary  to  the  realization  of  the 
required  integnry. 

The  information  about  the  data  integnry  require- 
ments of  each  user  area  can  be  developed,  documented 
and  presented  to  others  who  might  then  be  responsible 
for  data  secunry,  but  this  will  not  work  well.  It  dilutes 
the  responsibility  tor  secunry.  It  also  virtually  assures 
some  intentional  warping  of  the  data  presented  to  the 
secunry  staff  to  induce  them  to  do  what  the  users  want 
them  to  do. 

The  data  processing  staff  are  rarely  in  a position  to 
evaluate  the  qualify'  ot  data,  to  determine  what  the 
quality  is  and  what  it  needs  to  be.  to  see  whether 
specific  fields  are  correct,  whether  they  have  been 
neglected,  or  whether  they  have  been  manipulated  in 
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support  of  an  attempted  theft.  Thus,  it  is  inappropriate 
that  the  DP  staff  be  put  in  the  position  of  defining  the 
controls  through  which  such  problems  can  be  identified 
and  minimized. 

WORKABLE  ASSIGNMENT  OF 
RESPONSIBILITIES  FOR  COMPUTER 
SECURITY 

In  the  table  immediately  below  are  listed  some  of  the 
more  important  tasks  necessary  to  a reasonably 
complete  computer  security  program.  For  each  we  have 
provided  an  indicator  of  which  group,  the  DP  staff  or 
the  users,  should  be  in  the  best  position  to  do  the  work 
described.  We  recognize  that  the  user  community  in 
any  particular  company  may  today  be  totally  unpre- 
pared to  do  many  of  the  things  we  have  said  are  best 
done  by  them,  but  that  condition  can  be,  and  in  several 
more  progressive  companies  has  been,  rectified. 


Security  factor 


Best  done  by 
User  areas  DP  staff 


1.  Estimating  the  cost  of 
technical  security' 
measures,  such  as 
logging,  access  control, 
back-up  of  secondary 
storage,  etc 

2.  Contingency  planning 

(a)  Provision  of  data  X 

on  consequences 

of  disruption 

(b)  Preparation  of 
plan 

3.  Data  integrity  X 

requirements 

4.  Value  of  controls  in  X 

terms  of  displaceable 

loss 

5.  Source  of  information 
and  general  guidance 
in  all  technical  aspects 
of  computer  security. 

Assistance  to  users 

in  understanding 
technical  security 
exposures 

6.  Human  factors  aspects.  X 

including  need  for  and 
probable  effectiveness 

of  controls  for  holding 
individuals  accountable 
for  each  record  entered, 
modified,  or  read 


X 


X 


X 


7.  Need  for  data  X 

classification  program 

(in  conjunction  with 
Legal  Department) 

8.  Devising  a data 
classification  program 
(in  conjunction  with 
Legal  Department) 

9.  Evaluation  of  data  to  X 

detect  errors  and 
intentional  misconduct 

10.  Controlling  security-  X 

related  misconduct  by 
user-area  employees 

11.  Controlling  security- 
related  misconduct  bv 
DP  staff 

12.  Preventing  damage 
from  technical 
intrusions  by  outsiders, 
such  as  through  in-dial 
ports,  wiretapping,  etc. 
as  may  be  cost-justified 
by  users 

13.  Installing,  maintaining, 
and  administering 
access  control 
programs,  such  as 
RACE.  ACF2.  TOP 
SECRET.  DB  Secure, 
and  Guardian 

14.  Determination  of  who  X 

is  to  access  what  data 

15.  Integrity  of  software 
developed  in-house  or 
which  they  have  been 
asked  to  evaluate 


X 


X 

X 


X 


X 


Primary  responsibility  for  the  security  of  data  should 
be  placed,  by  corporate  policy,  with  the  respective 
functional  areas  which  are  the  principal  users  of  each 
data  aggregation.  As  we  have  noted  above,  they  are  in 
the  best  position  to  assess  the  importance  of  those  data 
to  the  whole  enterprise,  to  assess  the  consequences  of 
any  loss  of  data  integrity,  to  control  the  people  who 
have  the  greatest  influence  on  data  integrity,  and  who 
are  responsible  to  the  corporate  management  for  the 
successful  conduct  of  the  functions  supported  by  those 
data. 

Secondary'  responsibility  should  be  placed  on  those 
to  whom  access  to  data  is  given  by  those  with  primary 
responsibilirv  Secondarv  responsibility  entails 
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mandatory  compliance  with  the  security  guidelines 
established  by  those  with  primary  responsibility  for 
those  particular  data. 

The  data  processing  organization  should  have  only 
custodial  responsibility  for  the  data  which  are  under 
their  direct  control  so  that  they  can  provide  safeguards 
agreed  upon  with  those  having  primary  responsibility. 
In  addition,  the  data  processing  organization  should 
establish  a Computer  Security  Competence  Center 
with  a size  appropriate  to  the  needs  of  the  particular 
organization.  This  group  should  have  the  following 
roles  and  responsibilities: 

• Provide  advice  and  consultation  to  the  user  com- 
munity on  computer  security  matters. 

• Maintain  awareness  of  the  state-of-the-art  in 
computer  security  through  professional  organiza- 
tions and  peer  contacts  so  as  to  bring  early 
awareness  to  the  DP  staff  and  the  users  of  significant 
developments  in  both  security'  measures  and  evolving 
problem  categories. 

• Administer  the  access  control  package(s)  which  run 
on  facilities  under  control  of  the  DP  organization. 
In  this  role,  the  administrator  will  only  permit  access 
to  those  persons  authorized  access  by  those  with 
primary  responsibility  tor  data  security. 

• Take  leadership  responsibility  for  determining,  by 
working  with  the  user  areas  and  the  Legal  Depart- 
ment. the  need  for  a data  classification  programme. 
If  one  is  needed,  take  the  lead  in  developing  one  that 
satisfies  the  potentially  diverse  needs  of  the  user 
community. 

• Develop  an  Employee  Data  Security  Awareness 
Programme  which  will  adequately  sensitize 
employees  to  the  importance  of  their  cooperation  in 
the  corporate  data  security  program. 

• Develop  educational  programmes  for  user-area 
management  in  the  use  of  currently  available  audit 
packages  for  the  critical  review  and  evaluation  of 
their  data.  These  users  need  to  be  able,  whenever 
possible,  to  detect  data  integrity  problems  before 
they  become  any  more  costly  than  necessary.  This 
matter  is  complex  and  quite  beyond  the  scope  of  this 
particular  paper  — but  it  is  nevertheless  very 
important. 


• Extract  from  the  user  community  sufficient  infor- 
mation about  the  dependence  of  each  on  the 
continued  availability  of  theirdata  andofthe  means 
of  processing  them  and  about  the  economic  conse- 
quences to  the  enterprise  of  their  loss  forming  a 
basis  for  the  formulation  of  a contingency  pian. 
Again,  a complete  discussion  of  contingency 
planning  is  beyond  the  scope  of  this  paper,  but  it 
should  be  made  clear  that  responsibility  for  the 
development  of  contingency  plans  for  facilities 
under  control  of  the  data  processing  organization 
should  be  with  this  group. 

• Develop  an  educational  programme  which  provides 
guidelines  in  PC  security',  including  back-up  and 
recovery,  for  the  whole  enterprise. 

CONCLUSION 

Every  experienced  reader  will  realize  that  what  has 
worked  well  for  others  will  not  necessarily  work  well  in 
his  particular  situation.  The  plea  here  is  not  for 
complete  emulation  of  what  others  have  done  success- 
fully in  establishing  responsibility  for  data  security,  but 
only  recognition  of  the  factors  which  influenced  those 
who  have  been  successful  in  establishing  workable, 
relatively  unobtrusive  and  yet  credible  computer 
security  arrangements  in  their  organizations. 

Experience  in  consulting  on  computer  security  with 
a few  hundred  companies  in  a quite  diverse  arra\  of 
industry  areas  leaves  one  completely  convinced  that 
the  primary  responsibility  for  data  security  must,  in 
almost  all  companies,  be  with  the  user  communip.  if  it 
is  to  be  realistic,  adequately  comprehensive,  and  cost- 
effective.  There  is  an  important  computer  security  role 
indeed  for  the  data  processing  organization,  but  that 
role  should  not  include  seeking  or  accepting  primary 
responsibility  for  the  security  of  the  users'  data. 
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Hiring  a security  consultant  be- 
fore you  need  to  rescue  your 
data  from  a virus  can  be  far  less 
costly  than  hiring  that  consultant  after 
the  virus  has  done  its  dirty  work.  And,  if 
you  call  the  right  SDecialist,  you  may 
hear  some  things  about  security  that 
will  surprise  you.  For  example,  the 
consultant  might  tell  you  that  75  per- 
cent of  the  protection  you  need  is 
administrative,  not  technical.  You  may 
also  find  out  that  a reasonable  invest- 
ment in  a streaming  tape  backup 
system  could  avoid  serious  loss.  The 
most  important  question  the  consulant 
will  ask  you  is:  Why  do  you  think  you 
need  more  security  on  your  system? 

Exposure  Assessment 

Security  frequently  is  compared  to 
locking  a door  in  your  house.  Certainly 
that  is  an  apt  comparison  in  some 
cases.  However,  I lived  in  a small  town 
in  Michigan  for  years  and  never  locked 
my  house.  I can  t recall  a robbery  in 
that  rural  community  during  the  time  I 
lived  there.  But  when  I moved  to  the 
Detroit  area,  it  was  a far  different  story. 
Everything  gets  locked.  Twice. 

The  level  of  security  I needed  was 
based  on  risk  and  exposure.  In  the 
small  midwestern  town,  my  risk  was 
not  great.  Everyone  knew  everyone 
and  crime  was  not  an  issue.  The  risk 
went  up  when  I moved  to  Detroit.  In  the 
small  community,  my  exposure  was 
limited;  I had  one  computer  and  it 
wasn't  worth  the  trouble  to  steal.  Also,  I 


lived  in  an  apartment.  A burglar  would 
have  had  to  break  into  my  home  by 
passing  several  other  apartments, 
some  of  which  had  snoopy  neighbors 
watching  every  move  in  the  area.  By  the 
time  I moved  to  a house  in  the  city.  I had 
a lot  more  equipment  to  lose  and  fewer 
neighbors  to  keep  watch.  So  I was  not 
only  at  greater  risk,  I was  more 
exposed. 

Security  begins  with  an  honest 
assessment  of  what  you  can  afford  to 
lose  and  how  likely  you  are  to  lose  it. 
Let's  start  with  what  you  can  afford  to 
lose.  Government  agencies  have  esti- 
mated that  it  can  cost  $2,000  per  MB  of 
lost  data  to  replace  data  after  an 
intrusion  or  accident  (accidents  cost 
users  a lot  more  data  than  intruders 
do).  But  if  your  data  is  trivial  and  well 
backed  up,  is  it  really  necessary  to  go 
to  great  expense  to  protect  it?  Data 
loss  could  be  limited  to  one  work  day  if 
you  back  up  properly. 

Furthermore,  if  data  resides  on  a 
LAN  of  fewer  than  20  workstations  with 
no  connection  to  the  outside  world, 
how  great  is  your  exposure?  The  truth 
is  that  your  risk  and  exposure  are  likely 
to  be  greater  due  to  careless  users 
than  determined  crackers. 

The  first  question  to  ask  yourself 
when  assessing  your  risk  is:  At  what 
point  is  it  more  expensive  to  reenter 
lost  data  than  it  is  to  prevent  the  loss?  If 
you  can  recreate  a week's  worth  of 
data  entry  in  a half  hour,  it  probably 
doesn't  make  a lot  of  sense  to  spend 
thousands  of  dollars  on  sophisticated 
security  and  backup  equipment.  But  if 
you  have  very  heavy  data  entry,  loss  of 
a half  day's  input  could  be  disastrous. 
Almost  any  reasonable  cost  to  prevent 
loss  would  be  justified. 

How  about  exposure?  The  box 
lists  questions  to  help  you  determine 
how  exposed  your  data  is  to  loss.  Other 
exposure  factors  not  listed  might  be 
peculiar  to  your  installation.  Physical 
office  layout  can  have  a big  impact.  Not 
only  does  do  intruders  play  a part  in 
exposure,  but  also  the  cleaning 
crew  — it  could  hit  the  server  power 


cord  with  a vacuum  cleaner  and  crash 
your  LAN  while  the  night  crew  is 
entering  data. 

If  you  get  the  idea  that  a big  part  of 
risk  and  exposure  assessment  is  a 
combination  of  common  sense  and 
heading  Murphy  off  at  the  pass,  you're 
very  close  to  the  target.  It's  a fact  of  life 
that  more  data  is  lost  and  damaged 
through  carelessness  than  through 
planned  intrusion. 

LAN  Babysitting  101 

As  the  network  supervisor,  you 
have  100  percent  of  the  responsibility 
for  keeping  your  data  secure.  Once  you 
formulate  a realistic  assessment  of 
your  risk  and  exposure,  you  need  to  put 
together  a security  plan.  Remember 
that  a part  of  any  risk  and  exposure 
assessment  is  political.  The  issue  may 
be  less  what  you  feel  your  company  can 
afford  to  lose  and  more  what  your  boss 
feeis  the  company  can  lose.  Manage- 
ment never  wants  to  lose  any  data.  You 
know  you  can  afford  a certain  level  of 
loss  before  it  begins  to  make  sense  to 
spend  money  to  prevent  it.  Err  on  the 
side  of  conservatism. 

While  you  may  be  correct  in  your 
assessment  of  normal  conditions,  con- 
ditions are  rarely  normal.  Workers  get 
sick,  power  goes  funny,  equipment 
fails,  all  at  the  time  when  you  have  to 
replace  lost  data.  Give  yourself  a bit  of 
slack  as  you  plan  for  security.  It’s  a law 
of  nature  that  you'll  need  it. 

When  you've  built  your  security 
plan,  write  it  down.  Every  network  with 
more  than  10  users  should  have  a 
written  security  manual.  Two  reasons 
are  behind  this  necessary  step.  First, 
with  a security  manual,  you  do  away 
with  any  questions  about  how  the 
network  is  to  be  run  and  how  to  recover 
from  a disaster  Second,  creating  such 
a manual  is  a step  toward  taking 
network  administration  more  seriously. 
Because  most  data  loss  is  accidental,  It 
follows  that  accidents  can  be  mitigat- 
ed, if  not  prevented,  when  users  have  a 
healthy  attitude  toward  LAN  security. 

Now  the  hard  part  starts:  enforce- 
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the  exposure.  When  LANs  grow  larger, 
it  is  a good  idea  to  have  workgroup 
administrators.  With  many  users,  you 
need  greater  security  and  more  strin- 
gent controls  on  how  the  network  is 
used. 

la  your  data  organized  on  a need- 
to-knaw  basis? 

This  may  be  the  most  important 
question  affecting  exposure.  The  best 
security  against  common  accidents 
and  errors  is  to  keep  users  out  of  data 
they  have  no  reason  to  use.  This  is  a 
two-level  task.  First,  it  applies  to  data 
segregation  based  on  the  employee’s 
right  to  the  information.  Second,  it 
implies  that  novices  should  be  limited 
to  the  areas  in  which  they  are  thor- 
oughly trained. 

The  importance  of  keeping  users 
restricted  to  the  data  they  both  need 
and  know  how  to  use  can't  be  overem- 
phasized. Management  consultants 
evaluating  network  administration  of- 
ten find  large  amounts  of  data  opened  i 
to  corruption  by  naive  users  who  have  | 
no  need  to  get  anywhere  near  that  1 
information.  Also,  when  data  and  pro-  j 
■ grams  are  available  to  all  users  on  a 
large  network,  deliberate  damage  by  a 
disgruntled  employee  becomes 
greater. 

Do  you  interconnect  with  other 
networks? 

From  a technical  standpoint,  this 
1 has  the  greatest  potential  for  introduc- 
| mg  damage  from  intentional  or  unin- 
tentional virus  attack.  The  big  difficulty 
is  that  usually  there's  no  way  of 
! tracking  down  a virus  or  knowing  that 
I it’s  being  introduced  until  it’s  too  late. 

I If  you  interconnect  with  other  networks 
automatically  (polling  schemes  and  the 
| like),  you  need  to  be  careful  of  where 
i executable  programs  go  when  they're 
introduced  into  the  system.  And  you 
need  to  keep  a detailed  audit  trail  of  ail 
internetwork  connections.  Know  to 
whom  you’ve  connecting,  when  you 
connected,  and  what  happened  during 
the  connection. 

Also,  executable  files  (not  data) 
must  be  isolated  after  they  are  trans- 
ferred to  your  network  until  you  can 
check  them  for  contamination  or  dam- 
age. A damaged  program  can  unpre- 
dictably  hang  your  network.  File  trans- 
fers of  archived  files  can  often  produce 
1 unpredictable  results  when  you  want  to 
unpack  the  file. 

How  high  is  user  turnover? 

When  user  turnover  is  hign,  addi- 
tional levels  of  isolation  for  those  users 
in  sensitive  areas  is  a must.  This  is  one 
of  those  rare  situations  that  demands 
periodic  password  changes. 

I have  some  strong  opinions  about 


ment.  That's  a very  strong  word  for  a 
simple,  nonthreatening  concept  that 
boils  down  to  positive  attitude  reenfor- 
cement.  The  network  administrator  is. 
in  most  cases,  a babysitter.  He  or  she 
spends  a lot  of  time  teaching,  hand- 
holding, and  inconspicuously  watching 
network  users.  Developing  positive 
attitudes  about  safe  computing  is  one 
of  the  most  important  parts  of  the  LAN 
supervisor’s  job.  When  the  administra- 
tor fails  to  do  that  part  of  the  job  well, 
the  rest  of  the  job  is  far  more  difficult. 

After  Groundwork,  Action 

Now  that  we've  set  the  stage,  let's 
address  the  threats,  risks,  and  expo- 
sures with  guidelines  to  keep  your 
network  safe.  A rule  of  thumb  is  never 
risk  more  than  you  can  afford  to  lose. 
Now  we  ll  return  to  our  exposure  list 
and  answer  some  of  those  questions 
the  way  you  should  be  able  to  if  your 
LAN  is  secure.  By  secure  I mean  within 
the  context  of  your  level  of  acceptable 
risk  and  exposure.  There  are  no  (or,  at 
least,  very  few)  absolutes  when  it 
comes  to  answering  the  questions. 


How  well  trained  are  your  users? 

Training  is  key  to  good  network 
administration  and  safe  computing.  An 
unbelievable  amount  of  data  is  lost  or 
corrupted  because  inexperienced  us- 
ers made  errors  that  eouid  have  been 
prevented  by  training.  Often  preven- 
tion comes  from  simply  knowing  what 
they  can  and  can’t  do  on  the  network. 
Every  new  user  should  read  the  com- 
pany security  manual.  The  manual 
should  be  reread  periodically  as  a 
refresher. 

Often  the  ability  to  avoid  data  loss 
starts  with  the  recognition  that  some- 
thing has  gone  wrong.  Users  are  your 
best  observers  of  network  perfor- 
mance. They  need  to  be  trained  so  that 
they  can  be  network  assets,  not 
liabilities. 

“Magic  key’’  sequences  should  be 
avoided  unless  a solid  menu  system  is 
in  place  on  your  LAN.  Users  should 
understand  their  computing  environ- 
ment, not  just  the  keystrokes  to  do  a 
job. 

How  many  users  do  you  have? 

The  larger  the  network,  the  greater 
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password  changes,  by  the  way.  Con- 
ventional wisdom  says  that  passwords 
should  never  be  shared  and  should  be 
changed  frequently,  often  by  the  sys- 
tem itself.  I don’t  completely  agree  with 
conventional  wisdom:  Humans  react 
negatively  to  frequent  password 
changes.  People  tend  to  move  their 
data  to  the  hard  disk  (if  they  have  one} 
on  their  own  PCs  to  avoid  using  the 
LAN  if  security  gets  in  the  way  of  utility. 
This,  of  course,  is  what  you  don’t  want 
to  happen. 

So  if  you  have  a high-user  tur- 
nover, isolate  workgroups  on  the  LAN. 
Virtually  all  network  operating  systems 
allow  the  formation  of  groups.  For 
sensitive  groups  assign  a two-level 
password  scheme.  The  first  level  is  for 
the  group.  The  second  is  for  individ- 
uals, Change  the  group  password 
whenever  you  suspect  a compromise 
or  have  a turnover  in  the  group.  Let  the 
users  change  their  passwords  when 
they  wish.  Keep  the  group  passwords 
simple.  Discourage  putting  user  pass- 
words on  boot  disks,  but  allow  the 
group  password  to  be  automated  if  you 
feel  that  you  have  adequate  security  of 
! the  boot  disks. 

Do  you  have  dial-in  or  dial-out 
phone  lines? 

This  is  a variation  on  internetwork- 
' ing  and  carries  the  same  warnings, 
with  one  exception.  If  dial-out  lines  are 
accessible  universally,  you  stand  a 
serious  risk  of  abuse.  If  every  user  can 
easily  dial  out  on  a modem,  there  will 
be  a tendency  to  connect  to  Bulletin 
| Board  Systems  (BBS)  and  other  time- 
wasting,  potentially  dangerous  | 
sources  of  data  and  files.  You  do  not 
i want  uncontrolled  downloads  of  files 
from  BBSs,  which  are  a primary  source 
of  virus  infection.  Also,  many  BBS 
systems  are  toll  calls. 

What's  the  solution  when  you  have 
a legitimate  need  for  dial  out7  Start  by 
j using  a communications  server.  A 
communications  server  is  a separate 
machine  on  the  LAN  that  allows  net-  ! 
work  users  to  connect  to  the  outside 
wono  througn  one  modem.  To  make 
this  more  attractive,  you  might  consid- 
er a combination  facsimile  and  modem 
board:  you  have  the  advantage  of 
making  both  dial  out  and  fax  available 
to  all  network  users. 

But  here's  the  catch.  Since  the 
communications  server  s use  can  be 
restricted,  you  can  do  two  things.  First, 
you  can  restrict  who  uses  it  and  wnen. 
Second,  you  can  keep  a detailed  log  of 
all  communications  server  activity. 
With  these  two  controls,  those  who 
need  outside  connection  can  have  it, 
under  your  scrutiny,  and  you  will  know 


what  they  did  use  an  outside  connec- 
tion and  when. 

Are  disl°out  lines  accessible  to 
ail  users? 

Following  up  on  the  preceding 
question,  the  answer  to  this  one  is 
usually  no.  All  users  rarely  need  out- 
side connections.  When  they  do,  how- 
ever, use  the  communications  server 
approach  and  write  scripts  that  auto- 
mate (and  restrict}  the  outside  num- 
bers to  which  users  can  connect. 

Do  you  have  a procedure  for 
screening  new  software  before  it  is 
placed  into  service  on  your  LAN? 

Never  allow  a new  program,  re- 
gardless of  where  it  came  from,  on  your 
network  until  you  have  screened  it. 
Screening  has  several  levels.  For  a 
commercial  program  delivered  from  a 
legitimate  supplier  in  its  shrinkwrap, 
screening  may  consist  of  checking  the 
package  for  damage  and  installing  it. 
For  a utility  brought  in  by  an  employee, 
screening  may  include  a virus  scan  on 
an  isolated  PC. 

Never  load  an  executable  program 
that  isn’t  delivered  directly  from  a 


commercial  supplier.  Don't  allow  disk 
swapping;  it’s  piracy,  illegal,  and  dan- 
gerous. Discourage  personal  pro- 
grams on  your  LAN,  but  If  you  do  allow 
it,  screen  them  for  damage  or  viruses. 
Do  your  screening  on  an  offline,  isolat- 
ed (standalone)  PC.  Include  such  pro- 
cedures as  scanning  with  antivirus 
programs,  moving  the  system  date 
forward  to  dates  such  as  April  1,  Friday 
the  13th,  or  Columbus  Day,  and  check- 
ing files  on  the  isolated  machine  for 
changes  in  length. 

How  many  network  administra- 
tors do  you  have? 

On  large  LANs,  you  may  need 
multiple  network  administrators.  Net- 
work administrators  can  have  a lot  of 
power.  And,  If  they  are  disgruntled, 
they  can  do  a lot  of  damage.  If  you  must 
use  several  administrators,  grant  privi- 
leges selectively;  that  is,  avoid  global 
privileges  for  all  but  the  main  network 
administrator.  Give  local  admmistra-  j 
tors  the  privileges  they  need  within 
their  work  or  responsibility  areas.  Stick 
to  the  need-to-know  rule  with  adminis- 
trators and  users  and  you  won’t  go 
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wrong. 

How  do  your  users  boot  their 
machines? 

There  are  many  ways  to  boot 
machines  on  a LAN.  Putting  the  boot 
files  on  the  hard  disk  is  convenient,  but 
it’s  also  a good  way  to  invite  unauthor- 
ized use.  So.  unless  your  LAN  is  very 
small,  don’t  give  in  to  temptation.  Use 
floppy  boot  disks  and  keep  them 
secure  when  not  in  use.  How  secure 
goes  back  to  the  risk  and  exposure 
assessment  discussed  earlier. 

What  hardware  comprises  a typi- 
cal workstation? 

The  ideal  workstation,  for  security 
and  utility,  is  the  diskless  workstation. 
They  can’t  be  force-booted  by  an 
inside  hacker,  they  tend  to  have  more 
useable  application  memory,  and  they 
are  usually  nice,  easy-to-use  color 
monitors.  They  also  cost  more  than 
many  PCs  and  most  networks  grow  out 
of  a collection  of  single-user  comput- 
ers, which  are  converted  for  LAN  use. 

How  can  you  have  your  cake  and 
eat  it  too?  If  you  determine  that  you  are 
at  risk  and  highly  exposed,  make  it  a 
rule  to  replace  old,  dying  PCs  with 
diskless  workstations.  When  you  need 
a new  workstation,  make  it  diskless.  If 
i that's  overkill  for  your  situation,  limit 
workstations  with  hard  drives  to  those 
users  who  absolutely  must  be  offline 
from  time  to  time,  or  to  server  users  on 
a oeer-to-peer  LAN  with  nondedicated 
servers. 

What  is  the  typical  state  of  user 
morale? 

Low  morale  demands  high  securi- 
ty. After  accidents,  the  most  common 
source  of  damaged,  compromised,  or 
lost  data  is  tne  disgruntled  employee. 
These  folks  are  very  dangerous  be- 
cause they  are,  in  security  terms, 
i trusted  users.  They  also  are  often  hard 
to  ferret  out  since  they  rarely  signal 
' their  intentions  to  intrude  company 
data.  They  also  know  how  to  use  the 


This  is  similar  to  the  dial-out  line 
problem,  but  not  as  tough  to  handle. 
These  connections  are,  usually,  dedi- 
cated and  controlled  at  the  mainframe 
end.  A good  bet,  though,  is  to  include 
the  connections  on  the  communica- 
tions server  described  earlier.  If  you 
confine  all  outside  communications  to 
a communications  server  or  appropri- 
ate bridge,  you’ll  control  access  with- 
out getting  in  the  user’s  way. 

What  it  your  backup  procedure? 

Volumes  could  be  written  on  how 
to  back  up  your  LAN.  But  it  ail  boils 
down  to  two  pieces  of  advice:  do  it  and 
use  a grandfather  system.  You  should 
back  up  as  frequently  as  your  situation 
demands.  That  could  be  several  times 
a day  in  extreme  cases,  but  it  should  be 
at  least  daily. 

By  grandfathering,  you  use  a 
schedule  that  insures  that  you  won’t 
lose  important  data,  even  if  you  are  hit 
by  a virus.  First,  make  a baseline 
backup  so  every  file  on  the  LAN  is 
backed  up.  It  is  the  basis  you'll  use  if 
you  must  restore  the  entire  system. 
Second,  make  daily  backups,  which 


you  keep  until  the  end  of  the  week.  At 
week's  end,  you  do  the  weekly  back  up, 
which  you  keep  for  a month.  Return  the 
daily  tapes  to  use  for  next  week’s 
backups. 

Now,  each  month,  do  a monthly 
backup,  which  you  keep  for  a year. 
Thus,  you  have  four  dailies.  On  Friday, 
you  keep  a weekly.  At  the  end  of  the 
month,  you  have  four  weeklies.  At  the 
end  of  the  year,  you  have  12  monthlies. 
And  you  always  have  the  baseline 
backup.  Only  back  up  files  that  change 
(incremental  backup).  Then  when  you  i 
need  to  restore  an  entire  drive,  you 
start  with  the  baseline  and  then  update 
with  the  most  recent  incremental 
backup.  If  you  find  a virus  in  your 
backup,  you  can  move  to  an  earlier 
backup  (that’s  why  you  grandfather) 
and  the  worst  you’ll  have  to  do  is  J 
reenter  a month’s  worth  of  data. 

Do  you  have  a disaster  recovery 
plan? 

It's  a subject  in  itself,  but  the 
bottom  line  is,  you'd  better.  If  you  don’t 
have  a plan,  you'll  lose  data.  It’s  not  if 
it’s  when. 


j LAN. 

What  applications  do  you  run? 

Database  applications  are  the 
most  vulnerable  to  intrusion.  They  are 
also  the  most  likely  to  sustain  severe 
loss  if  compromised.  However,  indus-  j 
trial  strength  databases  often  have 
audit  trails  and  individual  passwords,  j 
Make  constant  use  of  audit  trails,  and 
use  nested  passwords  in  accordance 
.vith  your  risk  and  exposure  assess- 
ment. Remember,  people  won't  use 
applications  that  are  too  confusing  or 
time  consuming  to  access.  So  use 
balance  to  protect  your  data  without 
discouraging  authorized  access. 

Do  you  connect  to  mainframes  or 
minicomputers? 
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How  do  your  users  view  network 
security? 

This  is  a tough  one.  If  you  use  too 
much  security,  your  users  may  avoid  it. 
You  don’t  want  that.  Part  of  the  reason 
for  a LAN  is  that  you  can  control  the 
data  your  company  uses  to  keep  it  pure 
and  up-to-date. 

The  solution  is  to  use  as  much 
security  as  your  risk  and  exposure 
assessment  demands.  Educate  your 
users  about  the  level  of  security  you 
deem  appropriate.  Keep  education 
positive  and  upbeat  and,  if  possible, 
don’t  provide  a place  for  your  users  to 
offload  data  and  avoid  LAN  use 
altogether. 

How  complicated  is  your  current 
security  scheme? 

Continuing  in  the  same  vein,  the 
least  complicated  security  is  used 
consistently.  But  don’t  be  tempted  to 
automate  the  login  process  unless  your 
boot  disks  are  well  secured.  It’s  never  a 
good  idea  to  include  passwords  on 
boot  disks,  though.  If  you  must  auto- 
mate, leave  out  that  one  important 
aspect.  First,  it  invites  intrusion.  Sec- 
ond, it  comclicates  later  changes  to 


passwords. 

How  clean  and  consistent  is  your 
power? 

This  is  often  overlooked.  You  can 
lose  lots  of  data  with  no  intrusion  or 
user  accident  if  you  connect  to  dirty 
power.  If  your  risk  assessment  includes 
dirty  power,  get  an  Uninterruptable 
Power  Supply  (UPS)  for  every  vulner- 
able computer.  Here  again,  use  your 
risk  and  exposure  assessment  to  de- 
cide where  you  need  a UPS. 

Keeping  it  Your  Business 

The  bottom  line  for  LAN  security  is 
very  simple.  Decide  what  you  realisti- 
cally need  in  security  with  your  risk  and 
exposure  assessment  and  then  apply 
the  security  measures.  Have  a disaster 
recovery  plan  and  a written  security 
document  that  lays  down  policies  and 
procedures. 

Infuse  your  users  with  a sense  of 
security  and  responsibility  for  the  data 
on  your  company’s  LAN.  Isolate  users 
and  subadministrators  to  the  data  they 
need  to  use.  Perform  regular,  grand- 
fathered incremental  backups  and 
maintain  a detailed  audit  trail  of  LAN 


activity  so  that  if  you  do  have  a problem 
you  can  track  it  down  more  easily.  Limit 
or.  at  least,  control  access  to  outside 
systems.  If  you  must  internetwork,  be 
sure  that  you  maintain  audit  trail  re- 
cords, again,  to  track  down  problems. 
Finally,  screen  all  new  software  before 
you  put  it  on  your  LAN. 

Security  is  as  much  about  prevent- 
ing data  loss  from  errors  as  it  is  about 
preventing  intrusion.  And  intrusion, 
when  it  occurs,  is  likely  from  someone 
inside  the  company.  You  can  gain  a lot 
of  additional  security  on  your  LAN  if 
you  use  common  sense  and  apply 
businesslike  administrative  proce- 
dures. Security  is  meant  to  keep  your 
business  your  business.  But  it’s  also 
meant  to  help  users  do  their  jobs  safely 
and  conveniently.  If  you  carefully  per- 
form risk  and  exposure  assessment, 
you  will  have  a system  that  can  work  for 
your  company  and  give  you  far  fewer 
headaches.  □ 
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NIST  Group  Explores  Risk-Assessment  Packages 

Works  to  understand  assets,  vulnerabilities,  threats  and  costs  of  safeguards 


By  GARY  H.  ANTHES 

Security  specialists  from  the 
National  Institute  of  Standards 
and  Technology  and  the  Na- 
tional Computer  Security 
Center  (NCSC)  have  embarked 
on  a project  to  dream  up 
disaster  scenarios  - the  worst 
nightmares  of  computer  manag- 
ers, including  computer  center 
fires,  destruction  of  data,  vi- 
ruses and  other  mischief. 

Anticipating  the  worst  is  all 
in  a day’s  work  for  the  people 
in  NIST’s  Risk  Management 
Research  Laboratory,  estab- 
lished 18  months  ago  to  advance 
the  state  of  the  art  in  assessing 
and  managing  the  risks  associ- 
ated with  maintaining  and  using 
computer  systems. 

Putting  together  the  risk 
scenarios  is  the  second  phase 
in  a major  effort  by  the  lab  to 
improve,  expand  and  standard- 
ize the  paten-quilt  of  methods 
that  have  evolved  for  identify- 
ing risks  and  for  safeguarding 
against  them.  In  the  first  phase, 
nearing  completion,  the  lab 
evaluated  two  dozen  risk- 
assessment  packages  and  used 
them  as  the  basis  for  construct- 
ing a conceptual  framework  for 
risk  management. 

The  laboratory  this  year  is 
funded  mostly  by  NCSC  - a 
unit  of  the  Defense  Depart- 
ment’s National  Security 
Agency  - and  staffed  by 
personnel  from  NIST.  The 
laboratory  was  established  in 
part  as  a response  to  an  Office 
of  Management  and  Budget 
directive  that  in  1985  mandated 
periodic  risk  analysis  for  ail 
federal  systems. 

It  also  was  formed  as  it 


became  apparent  that  the  need 
for  risk  management  was  in- 
creasing faster  than  the  sophis- 
tication of  the  tools  available  to 
support  it.  “Everyone  says  do 
risk  analysis,  but  no  one  really 
knows  how  to  do  it,”  said 
Eugene  F.  Troy,  head  of  the 
Computer  Security  Assistance 
Group  of  NIST’s  Computer 
Security  Division. 

The  software  packages  ex- 
amined so  far  all  reflect  differ- 
ent ideas  about  what  risk 
assessment  means,  he  said. 
“Risk  analysis  can  run  the 
gamut  from  back  of  the  enve- 
lope to  a quarter-million- 
dollar  report.” 

Basic  Framework 

Nevertheless,  the  packages 
have  provided  a basis  for  the 
framework,  which  Troy  said 
will  give  guidance  to  agencies 
that  wash  to  improve  the  secu- 
rity of  their  computer  systems 
and  facilities.  The  framework 
also  can  serve  as  a checklist  for 
preparing  requests  for  propos- 
als and  for  evaluating  vendor 
offerings,  he  said. 

The  objective  of  the  frame- 
work is  to  tie  together  m a 
systematic  way  key  elements 
involved  in  risk  management 
and  to  explain  their  relation- 
ships qualitatively.  The  ele- 
ments include  assets,  threats, 
vulnerabilities,  consequences, 
safeguards  and  the  cost  of 
safeguards. 

The  lab  also  will  present  for 
comment  drafts  of  its  risk 
scenarios. 

Each  of  the  packages  exam- 
ined so  far  addresses  part  of  the 
risk-management  process,  but 
none  is  all-encompassing,  said 


Irene  Gilbert,  who  heads  the 
lab.  Another  problem  is  that 
packages  alleged  to  measure 
the  same  things  do  not  always 
give  consistent  results. 

The  standard  test  scenarios 
— which  will  encompass  areas 
such  as  applications  software, 
computer  networks  and  data 
center  facilities  — ami  be  used 
to  evaluate  and  calibrate  the 
packages.  They  can  be  used  to 
see  if  a particular  package  or 
approach  is  able  to  identify  the 
security  flaws  built  into  the  test 
cases,  Gilbert  said. 

The  lab  will  not  develop  its 
own  packages,  nor  will  it  test 
or  endorse  them,  Gilbert  said. 
The  framework  and  scenarios 
may  be  used  by  agendes  and 


vendors  to  develop  new  nsk- 
management  methodologies, 
Gilbert  said.  “We  want  to 
encourage  vendors  to  develop 
packages  that  meet  the  require- 
ments of  a broad  spectrum  of 
computer  environments.” 

Troy  said  that  developing 
risk-management  packages  is 
not  a trivial  undertaking,  with 
companies  typically  investing 
more  than  $1  million  in  them. 

Work  on  the  framework  and 
the  test  cases  eventually  will 
find  its  way  into  a new'  Federal 
Information  Processing  Stan- 
dard on  risk  management  in 
federal  computer  environ- 
ments, The  FIPS  is  likely  to 
be  published  in  1991  or  1992, 
Troy  said.  ◄ 
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Crackdown 
on  software  pirates 

Industry  watchdogs  renew  efforts  to  curb  illegal  cofiyi ng 


BY  JANET  MASON 

Software  piracy  wears  a 
reputation  of  cloaked  in- 
trigue — Dick  Tracy 
tracking  down  illicit  re- 
tail  operations  on  crowd- 
ed Hong  Kong  streets 
and  corporate  bad  guys 
churning  out  pirated 
disks  for  companywide 
use. 

Less  notice  has  been  paid  to 
the  casual  pirate  — the  well- 
meaning  employee  who  replaces 

Masse  s i Phikdeiphu-bwed  free- 
lance  jourmfist. 


the  company-issued  word  pro- 
cessing program  with  his  own 
and  then  allows  co-workers  to 
copy  it  Or  the  staff  member  who 
pirates  company  disks  for  home 
use. 

But  more  and  more,  both 
types  of  pirates  are  finding  that 
they  are  risking  more  than  just  a 
guilty  conscience  by  illegally 
copying  software.  Corporations, 
computer  dealers,  rental  opera- 
tions, universities  and  bulletin 
boards  are  increasingly  being 
taken  to  task  by  software  indus- 
try watchdogs. 

In  recent  months,  industry 
trade  associations  have  begun 


stepping  up  educational  and  pre- 
vention efforts  as  part  of  an  anti- 
piracy crusade.  Groups  such  as 
Adapso,  a Washington,  D.C.- 
based  computer  and  software 
services  association.  Software 
Publishers  Association  (SPA) 
and  Business  Software  Alliance 
(BSA)  have  been  consulting  re- 
tailers and  the  publishing  indus- 
try on  how  to  avoid  copyright  in- 
fringements. 

Moreover,  the  maturing  soft- 
ware industry  has  begun  to  initi- 
ate the  same  protective  steps 
taken  by  other  intellectual  prop- 
erty industries,  such  as  movie, 
record  and  book  companies,  ac- 


cording to  legal  experts. 

"In  the  past  20  months,  (SPA) 
has  brought  30  lawsuits  against 
offenders,"  says  Mary  Jane 
Saunders,  SPA  general  counsel 
and  an  attorney  who  handles  do- 
mestic piracy  issues  (see  story 
page  115). 

"The  SPA  has  plastered  the 
world  with  brochures  to  inform 
people  that  piracy  destroys  the 
valuable  resource  of  commercial 
software,”  says  Dorm  B Parker, 
a senior  management  consultant 
at  Menlo  Park,  Calif. -based  SRI 
International,  Inc. 

The  general  notion  of  soft- 
ware piracy  as  an  unethical  prac- 
tice is  being  driven  home  by  ex- 
pensive lawsuits  brought  against 
major  corporations  and  other  of- 
fenders pirating  software. 

Although  those  who  make  il- 
legal copies  are  rarely  prosecut- 
ed, purchasers  of  large  amounts 
of  illegal  software  can  receive  a 
$50,000  fine  under  U.S.  Code 
Section  17  Copyright  Law. 

With  the  help  of  an  amended 
trade  act.  international  strides 
have  been  made  in  dosing  the 
doors  of  illicit  retail  and  mail-or- 
der software  operations  in  the 
Far  East  and  filing  lawsuits 
against  European  corporate  in- 
fringers. 

Counterfeits  abound 
Software  vendors  say  they  are 
fighting  for  their  very  existence 
in  moving  against  piracy. 

In  what  he  deems  a conserva- 
tive estimate  of  the  amount  of 
U.S.  illegal  software  in  circula- 
tion, Peter  Beruk  at  SPA  says 
that  "for  every  legal  software 
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IN  DEPTH:  SOFTWARE  PIRATES 


package  in  use.  there  is  another  illegal 

one." 

Some  say  that  that  number  is  as  high  as 
five  illegal  copies  for  every  legal  one.  adds 
Beruk.  who  is  a litigation  protect  manager 
at  the  Washington.  D.C.-based  associa- 
tion. 

Adding  fuel  to  the  fire  are  state  agen- 
cies. which  have  found  — in  a precedent- 
aettmg  court  case  involving  the  Universi- 
ty of  Califomi.'  at  Los  Angeles  — that 
they  are  currently  exempt  from  U.S. 
copyright  law.  And  rental  operations, 
both  legitimate  and  those  renting  pirated 
disks,  are  under  increasing  scrutiny. 
Along  with  personal  computer  software, 
which  is  easily  copied,  cumbersome  main- 
frame software  has  also  had  piracy  prob- 


lems. though  more  rarely. 

SRJ’a  Parker  defines  software  piracy 
is  a "cnmotd"  in  the  sense  that  it  a one  of 
a stnng  of  hot  computer  news  topics  that 
include  invasion  of  privacy,  hackers  and 
computer  viruses. 

"St  became  a crimoid  in  the  early 
1980*„"  Parker  explains.  "At  that  time, 
[software  piracy!  ***  senoualy  threaten- 
ing the  computer  industry  to  the  extent 
that  it  was  about  to  destroy  it." 

For  software  vendors,  the  intrigue  of 
piracy  translates  into  start  bottom-line 
losses.  Worldwide  hardware  and  software 
losses  from  copyright  infringement  total 
$4. 1 billion  annually,  says  Tom  Sherman, 
an  analyst  at  the  U.S.  International  Trade 
Communon. 


Since  then,  software  companies  have 
tried  a aeries  of  technological  solutions, 
such  as,  most  notably,  disks  that  cannot 
be  copied,  which  were  "all  thwarted  by  an 
army  of  hackers. " Sherman  claims. 

Warning  shat  flrsd 
Corporations  received  a warning  last  June 
when  Facta  on  file,  Inc.,  a New  York- 
based  publishing  company,  reached  a ux- 
ftgure  out-of-court  settlement  with  five 
software  vendors  that,  with  the  help  of 
SPA.  filed  a aurt  on  the  grounds  that  the 
company  had  coped  their  programs 

The  case  was  the  first  to  be  filed  by 
multiple  vendora  against  a corporation. 
SPA  has  also  settled  four  other  corporate 
piracy  cases  out  of  court  with  the  provi- 
sion that  the  organisations  names  would 
not  be  released.  Currently,  the  associa- 
tion has  aut  cases  pending  against  corpo- 
rations. 

Aa  a result  of  the  Facta  on  File  case,  a 
major  accounting  firm  potted  articles  per- 
taining to  the  Lawsuit  on  bulletin  boards  in 
all  of  its  corporate  locations  with  a memo 
from  top  management  saying,  "Don't  let 
this  ever  happen  to  us.”  SPA’s  Saunders 
points  out  that  the  same  firm  encourages 
its  clients  to  hive  corporatewide  piracy 
contracts  and  audits. 

SPA  has  pursued  informal  corporate 
software  audits  with  two  dozen  compa- 
nies to  avoid  the  expense  and  embarrass- 
ment associated  with  lawsuits.  With  the 
company's  cooperation.  SPA  sends  in  its 
own  investigator  to  compare  installed 
software  on  hard  disks  with  corporate 
purchasing  records. 


"When  we  find  pirated  software 
Saunders  explains,  “the  company  has  to 
destroy  it.  pay  us  a penalty  — which  is 
lesa  than  if  we  had  taken  them  to  court  «= 
and  then  buy  legal  copies  of  the  soft 
wire." 

He  says  that  his  organisation  has  found 
that  if  a company  does  not  pay  attention 
to  aoftwire  — despite  its  policies  — it  is 
likely  to  get  pirated  SPA  usually  suggests 
a corporate  audit  when  it  finds  a company 
with  an  unenforced  corporate  software 
policy.  The  association  also  provides.  a 
aelf-impoaed  contract  and  audit  program 
for  companies. 

Policy  neodod 

Parker  emphasues  that  a corporate  effort 
agiinat  software  piracy  starts  with  an  or 
gamzat tonal  policy,  backed  up  with  soft- 
ware audits  and  followed  up  by  swift  pun- 
ishment of  offenders. 

The  contract,  which  Parker  suggests 
employees  should  sigh  once  a year,  should 
state  that.  "We.  as  a company,  do  not  en- 
gage in  software  piracy,  and  our  purchas- 
ing function  should  pursue  site  licenses 
and  larger  scale  purchasing." 

Parker  says  the  contract  may  help  tne 
company  m a lawsuit  — provided  that  the 
policy  has  been  enforced.  Hu  recommen- 
dations come  through  SRJ's  Information 
Integrity  Institute,  which  acts  as  a clear- 
inghouse for  50  major  companies  to  share 
information  on  computer  security,  includ- 
ing piracy. 

Parker  also  suggests  that  companies 
cade  their  disks  by  buying  corporate  disks 
in  a certain  color  or  brand  so  that 


Copylefts  vs.  copyrights 


Mention  software  piracy  to  Richard  M. 
Stallman,  and  you’re  in  for  a novel  re- 
sponse. "What’s  that?"  he'll  ask.  It’s 
an  unusual  reaction  for  somebody  en- 
trenched in  the  software  industry. 
However,  given  Stallman's  back- 
ground — programmer,  computer  in- 
dustry outlaw  and  MIT'a  "last  hacker" 
— his  answer  is  far  from  surprising. 
"Software  licensing  is  antisocial. 

because  it  keep* 
information  away 
from  your  neigh- 
bora."  Stallman 
says,  "and  it  pro- 
hibits the  growth 
of  the  technol- 
ogy." 

Stallman  re- 
fuses to  use  any  li- 
censed commercial  software  >nd  has 
; spent  hours  in  a cramped  MIT  labora- 
' tory  developing  programs  that  enable 
j users  to  view  the  source  code  and  im- 
prove on  it  if  they  wish  3ased  on  the 
hackers  creed  that  all  information 
must  be  free  to  further  collective  soci- 
etal knowledge,  he  has  founded  The 
Free  Software  Foundation  as  a legal  al- 
ternative tocopynghted  software. 

Housed  on  MIT's  campus,  the  foun- 
dation provides  "copylefts"  that  en- 
sure programs  are  freely  distributed 
and  not  incorporated  into  for-profit 
programs.  Despite  ita  renegade  atti- 
tude. the  foundation  is  supported  by 
some  corporate  heavyweights.  The 
Next,  Inc.  computer  comes  bundled 
with  the  software.  Other  firms,  includ- 
ing Hewlett-Packard  Co..  Bull  H.  N.  In- 
formation Systems,  Inc..  Nynex  Corp. 
and  NCR  Corp.,  support  the  founda- 
tion. * 

The  programs  — which  run  on  Dig- 
ital Equipment  Corp.  VAXs,  other 
minicomputers  and  Intel  Corp.  30386- 
based  personal  computers  — are  not 
exactly  free.  They  are  sold  on  magnet- 
ic tapes  that  cost  S 1 50  plus  shipping 
and  handling.  However,  as  Jay  Fenla- 
son.  one  of  the  foundation's  two  full- 
time programmers,  says,  "Our  prima- 
ry purpose  is  to  develop  software,  not 
to  make  tapes,  so  we  try  to  discourage 
people  from  buying  tapes  and  instead 
make  copies  from  their  colleagues.'' 

The  foundation  distributes  an  en- 
j tire  development  system  that  ulti- 
j mately  will  include  applications  for 

j both  programmers  and  nonprogram- 

j mers  and  an  operating  system  that  re- 
portedly rivals  Unix. 


Currently,  the  meet  popular  pro 
gram  is  an  editor  called  Emacs.  The 
foundation  also  distributes  a widely 
used  compiler,  and  programmers  are 
working  on  a spreadsheet  product 

Desoite  the  high  level  of  corporate 
backing  — which,  along  with  individ- 
ual contributions,  supports  the  founda- 
tion — not  everyone  is  pleased  with 
what  the  group  stands  for. 

One  commercial  software  analyst 
accuses  Stallman  of  crating  an  operat- 
ing system  designed  “to  put  Unix  out 
of  business.”  Stallman  counters  this  by 
explaining  that  he  is  simply  creating  a 
program  that  people  need,  which  will 
further  3oaety  by  encouraging  the 
spread  of  knowledge. 

However,  there  are  those  who 
could  not  disagree  more  with  Stall- 
man's views.  Legal  threats  aside,  op- 
ponents say  that  pirating  software  car- 
ries repercussions  that  am  damage  the 
productivity  of  an  entire  industry  and 
individual  users. 

Mary  Jane  Saunders  at  Software 
Publishers  Association  (SPA)  argues 
that  software  piracy  negatively  affects 
all  users  by  driving  up  prices  and  di- 
verting funds  used  for  research  and  de- 
velopment. 

Saunders,  who  is  general  counsel  at 
the  association,  ays  that  about  15%  to 
20%  of  corporate  profits  are  returned 
to  R&D,  which  later  benefits  custom- 
ers m the  form  of  software  product  up- 
dates and  new  versions.  'If  vendora 
don't  have  the  revenue  to  match  distri- 
bution of  their  products,  they  don't 
have  much  to  return  to  R&D."  ahe 
ays. 

Ultimately,  piracy  could  result  in 
fewer  new  prod- 
ucts introduced 
to  market,  the 
ays.  "U  people 
are  stealing  ven- 
dors' property, 
there  is  no  incen- 
tive" to  develop 
new  packages, 
the  claims. 

Immediate  repercussions  of  rung 
pirated  software  include  the  lack  of 
documentation  and  technical  support. 
"In  the  short  term,  you  get  the  pro- 
gram." ays  Peter  Beruk,  SPA's  litiga-' 
tion  project  manager,  "but  you  won't 
receive  documentation  or  be  able  to 
call  the  support  number  without  a an- 
al number." 

JANET  .MASON 
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How  to  spot 
pirate  software 


To  determine  whether  adva* 
deed  auft wire  is  posted,  it  is 
best  to  use  the  adage  that 
"asythiag  that  aomds  too 
good  to  be  true  prehehly  is," 
says  Peter  Bmik  it  Software  PaMsh* 
ers  Association  (SPA). 

The  fest  telltale  stga  of  posted  soft- 
ware is  the  prioe.  Meet  najor  software 
programs  advertised  for  less  than 
$200  are  probably  flkgiiv  Berok  say*. 

The  aeouad  waransg  ngni  is  the  io» 
otise  of  the  road-order  boom,  "Stay 
alert  fee  Haag  Kc»&  the  Midffig  East 
and  the  Far  East,"  warns  PBar  Gaud. 


gaaitive  HHCut  at  Washington, 
D.Chsacd  Bamre  Software  Aaaod* 
atioe  (BSAX  Once  a catalog  is  re- 
ceived, coaewnen  am  edl  venders'  re» 
Spotui  representative*  to  Sod  out 
whether  the  source  » a authortxod  dt»- 
tribotor. 

Baramot  unauthorised  dtiptiratinn 
at  software  costs,  vendor  asaocattioae 

the®teohts^aaoseato«jMarre' 
port  auepetted  piracy. 

BSA  cm  be  reached  at  202*737° 
7060?  SPA'a  piracy  hot  hue  is  1-800* 
3SmPDUL 


employees  am  distinguish  between  cor- 
porate and  persona*  property.  "This 
T»ayt"  Patter  says,  "employees  are 
aware  that  they  are  engaged  in  illegal  ac- 
tivity with  company  materials." 

Saunders  says  that  "there  are  people 
is  corporate  America  who  understand 
copyright  law.”  Many  of  them  are  among 
the  20  callers  who  contact  SPA's  piracy 
hot  line  every  day  and  are  willing  to  sign 
an  affidavit  about  piracy  in  thar  comps* 
meat 

People  who  call  the  hot  line  indude  for- 
mer employees,  consultants  and,  in  one 
case,  a temporary  secretary.  This  secre- 
tary, who  writs  novels  in  her  spare  time 
and,  as  Saunders  observes,  "is  concerned 
with  protecting  her  own  intellectual  prop- 
erty,’' reported  three  piracy  incidents  at 
separate  com  jam®. 

PaaHwg  with  dealers 

Along  with  tracking  corporate  abuses, 
SPA  also  investigates  calls  about  comput- 
er dealers  and  bulletin  boards.  In  most 
cases,  SPA  tries  to  settle  out  of  court  on 
behalf  of  the  565  software  vendors  it  rep- 
resents. However,  Saunders  explains, 
there  are  many  cases  m which  litigation 
cannot  be  avoided,  la  a current  case,  SPA 
has  been  forced  to  take  a California  com- 
puter dealer  to  court  even  though  the 
dealer  contends  that  "the  only  time  it 
ever  loaded  a hard  disk  with  free  software 
was  when  our  (SPA)  investigator  wa* 
there." 

SPA  has  filed  suits  against  10  comput- 
er dealers,  and  its  efforts  and  corporate 
awareness  programs  may  be  paying  off 


with  fewer  lawsuits. 

Recently,  an  SPA  investigator  check- 
ing a report  of  piracy  in  a Florida  dealer- 
ship found  no  evidence  of  piracy  in  two 
dozen  other  area  stores,  "A  year  and  a 
half  ago,"  Saunders  ays,  "he  would  have 
found  at  least  half  of  them  doing  some- 
tMag  iUegad,  This  time,  he  even  farad  out 
brochures  in  some  of  the  stores," 

As  for  bulletin  boards,  although  the  as* 
satiation  has  pressed  charges  against  five 
systems  operators,  the  group  tends  to 
warn  those  involved  rather  than  filing 


ant.  "If  we  wasted  to,  we  could  fik  16 
stats  a day"  against  bulletin  beams, 
Saunders  ays.  Instead,  the  aasoeaoon 
contacts  the  systems  operators  to  let 
them  know  they  will  soon  be  mentored, 
thus  giving  them  a chance  to  remove  pi- 
rated  software. 

Even  fears  of  eaeeseasf  viruses  has 
not  discouraged  assay  bulletin  board  us- 
era  from  picking  up  dupdeated  software. 

Software  rental  firms  are  another  tar- 
get of  industry  watchdogs.  Firms  renting 
software,  even  if  it  is  a legal  operation,  ex- 


acerbate software  puscy,  say*  Ronald  Pa- 
lenski,  general  counsel  of  Adapso. 

To  curtail  this  threat,  legislation  is  un- 
der constdaratxm  by  the  House  and  the 
Senate  that  will  give  software  vendors  the 
right  to  restrict  rental  of  their  software.  If 
it  passes,  the  legislation,  which  mirrors 
rental  restrictions  for  record  companies, 
places  the  onus  of  risk  on  the  vendor.  This 
win  mean,  in  effect,  tbit  software  vendors 
themaeivea  wifi  deede  if  their  software 
an  be  copied, 

Orna  got  orwery 

Despite  trade  association  efforts,  the  pi- 
racy picture  is  not  completely  clear.  A 
preeedeat-setttaf  case  — and  one  chat 
has  aroused  the  ire  of  the  software  mdta* 
try  — is  one  m which  state  agenoes  were 
allowed  to  ptrate  software  without  paying 
damages. 

BV  Engineering  v.  the  University  of 
California  at  Las  Angeies  was.  first 
brought  to  district  court  in  1987,  decided 
in  1988  and  denied  a hearing  by  the  U.S. 
Supreme  Court  in  1989. 

The  case  determined  that  the  owners 
of  BV  Engineering,  whose  software  had 
been  pirated  by  the  engineering  tiepart- 
mem  at  UCLA,  had  no  standing  to' sue  for 
damages.  The  difference  between  the 
Bate  and  others,  Saunders  says,  & that 
the  Mate  an  receive  an  injunction  to  stop 
the  piracy  but  is  not  currently  liable  for 
damages,  court  costs  and  attbrney'sfees. 

Concerned  that  other  state  aggnoes 
will  be  encouraged  to  pirate  software,  last 
year  industry  advocates  introduced  reme- 
dial legislation  to  the  Copyright'  Act  of 
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1976  to  the  U.S.  Congress.  The  goal.  Pa- 
lensJd  explains,  “is  to  close  the  state 
agency  loophole." 

Dave  Eskra.  chairman  oi  both  Adapso 
and  Ptnaophic  Systems.  Inc.  in  Lisle.  QL. 
testified  before  the  Senate  Subcommittee 
at  Patents,  Copyrights  and  Trademarks 
that  since  the  decision,  it  has  become 
harder  to  dose  deals  with  state  agencies 


MINI  POLL 

Handling  a 
tough  issue 

How  do  you  handle  the 
sticky  issue  of  illegal 
software  duplication? 
We  asked  that  question 
of  some  IS  chiefs: 

DONALD  WHITTINGTON 

We  have  a written  policy  that  for- 
bids unauthorized  copying.  Howev- 
er, having  the  policy  is  one  thing, 
enforcing  it  another.  In  many  cases, 
it's  hard  to  track  the  originator,  and 
what  can  you  do  if  someone  comes 
in  after  hours  and  makes  copies? 

If  we  did  find  employees  copying 
software,  we'd  wans  them  against 
continuing  to  do  so.  I’ve  found,  how- 
ever. that  since  we've  put  our  policy 
in  writing,  illegal  copying  has  not 
been  a pro 01  em. 

CHRIS  PORCH 

- - ‘ -*  - - 

C impumr  OpTortowi 
Ncl  At  CMtw  f Advuon 
S«n  0<«9« 

We  do  not  have  a formal  policy  for 
dealing  with  duplication,  but  being 
pan  of  a Urge  bank  — Security  Pa- 
cific Bank  — - we've  got  auditors  in 
ben  once  or  twice  a year  to  take  in- 
ventory of  the  hard  drives.  The 
much  larger  issue  we're  worried 
about  is  viruses.  But  I do  warn  peo- 
ple that  pirating  software  is  not  con- 
doned, It’s  not  the  individual  that 
will  get  fired,  it's  toe.  Large  organi- 
zations like  ours  could  get  stiff  pen- 
alties if  copying  occurred.  I think 
the  courts  are  geared  toward  hang- 
ing corporations. 

We  buy  a lot  of  software,  and  I 
thmk  site  licenses  for  corporations 
our  sue  would  go  a long  way  m help- 
ng  us  combat  piracy. 


ALL£N  HEAD 


We  have  a formal  company  policy 
stating.  Thou  chait  not  duplicate 
software,  ' and  that  policy  is  well- 
enforced.  If  we  eaten  someone  a 
first  time,  we  ll  warn  him.  For  a sec- 
ond offense,  we  d have  to  take  more 
drastic  action. 

f^opte  are  not  restrained  from 
buying  software  for  their  work.  Lf 
they  need  Lotus  1-2-3.  we  11  buy  it 
for  them.  That  encouragement 
helps  deter  software  piracy. 


on  mainframe  software  sales  because  the 
agencies  have  no  incentive  to  license  the 
product. 

Paiensid  says  he  expects  the  legisla- 
tion to  be  passed  in  early  1990.  thus 
thwarting  piracy  by  state  organizations, 
although,  he  adds.  “In  this  town,  I 
wouldn't  be  surprised  by  anythin g,1' 

Beyond  U.S.  shores,  software  pirates  ao 
bort  halves  of  the  hemisphere  have  ben 
thick  as  thieves.  The  retail  and  mad-anier 
piracy  market  in  the  Fsr  East  has  recently 
been  compounded  with  corporate  piracy 
cases  in  Hong  Kong.  In  Europe,  corporate 
piracy  has  become  widespread  in  certain 
countries. 

Spurred  by  a msturism  microcompoter 
base  in  foreign  countries  and  amend- 
ments to  the  Ttade  Act.  the  software  in- 
dustry has  linked  hands  with  the  book 
publishing,  recording  and  motion  picture 
associations  under  the  auspices  of  the  In- 
ternational Intellectual  Property  Alliance 
(UFA),  formed  in  1985. 

Before  1984,  the  Trade  Act  contained 
provisions  that  provided  duty-free  entry 
of  goods  normally  tariffed  into  developing 
nations.  It  also  did  not  expressly  protect 
copyrighted  intellectual  property  of  any 
sort. 

With  a mature  market  in  instilled 
bases  of  microcomputers,  videocassette 
recorders  and  inexpensive  copying  tech- 
nology. the  heads  of  intellectual  property 
assadaooiis  found  rampant  copyright  in- 
fringements during  a trip  to  the  Far  East. 

Hence,  the  allied  industries  filed  a re- 
port with  the  U.S.  Trade  Representative 
oTtce.  which  passed  an  amended  Trade 
Act  explicitly  to  protect  intellectual  prop- 
erty in  foreign  countries.  If  the  countries 
do  not  comply,  the  U.S.  Trade  Represen- 
tative has  the  right  to  invoke  trade  sanc- 
tions. 

The  nPA  and  its  individual  members, 
including  BSA.  have  been  working  in  tan- 
dem with  the  European  Commission  (EC) 
on  a ssoftv  are  protection  directive. 

If  adopted,  the  directive  will  require 
the  12  EC  member  states  to  amend  their 
laws  to  protect  all  software  used  in  their 
country.  The  EC’s  Parliament  and  the 
Counsel  of  Mimstne*  are  expected  to  con- 
sider the  directive  in  the  first  quarter  of 
1990. 

"Essentially,  it  will  protect  the  con- 
cept that  when  you  open  a shrink- 
wrapped  package  cf  software,  it  implies 
that  a contract  has  been  entered.”  ays 
Douglas  E.  Phillips,  president  of  BSA  in 
Washington.  D.C. 

Recently.  BSA  has  filed  several  suits  in 
France  and  Italy  and  has  issued  a warning 
in  Spain.  Last  April,  in  a raid  of  Monte- 
dison. an  511  billion  Italian  corporate  coo- 
glomerate,  investigators  found  that  90% 
of  Lotus  Development  Carp-  and  Ashton- 
Tate Corp-  software  was  illegally  copied. 
Nine  months  later,  the  case  is  soli  in  prog- 
ress. 

Two  French  companies,  against  which 
BSA  filed  suit  last  October,  include  TeJe- 
diffusion  de  France,  a provider  of  trarta- 
misaion  services  to  the  broadcast  media, 
and  Banque  Pan  baa,  a financial  institu- 
tion. 

In  Spain,  BSA  has  tried  different  tac- 
tics by  announcing  to  the  press  that  the 
group  is  planning  to  conduct  a raid  against 
a maior  Spanish  corporation  “Every 
company  in  Spain  could  potentially  be 
raided.”  Phillips  says,  "so  this  is  a warn- 
ing to  them  to  stop  using  pirated  soft- 
ware.” 


Casualties  of  war 


Recent  events  is  the  war  on  piracy: 

• The  Buunere  Software  Aaenoatkn 
(BSA)  meats*  crimrel  proreofa m 
ipnt  Mapfre  Vida,  a Spared*  borer- 
anre  Arm,  far  aflsgad  iltagaf  software 
owjacJJwuAISSSe 

R*.  S.A.-.  at  B reretat  Sp ret  tar 

fro*  afleged  *»  af  vmatbarimd 
oopiw  of  software  merie  by  Aaisfon1 
T»eCcirpu.,l^^ 

ifisoaft  Carp,  set  WordPerfect 
Cat*/)#,  mm. 


Ptnlfip*  hopes  this  strategy  works,  fie® 
same  as  he  pass*  out.  BSA  ejrasber*  «*= 
which  indude  Aldus  Corp.,  Aahtoa-Tste, 
Autodesk.  Incd.  Lotus,  Microsoft  Corp. 
and  WordPerfect  Corp.  — “are  in  the 
biasness  at  developing  software,  not  titl- 
gatka.” 

In  the  Far  East,  cases  have  been  filed 
is  Hong  Kong,  Taiwan  and  Kota,  among 
other  ceuaeries.  And  BSA  is  vwrtaag  with 
the  Aopta's  Republic  of  China  to  enforce 
stronger  copyright  town, 

Wredred  sMpecMimein 

The  biggest  success  story,  perhaps,  is 
Singapore..  Phfifips  reports  that  a year 
ago,  “pirated  software  was  earned  by 
plenty  of  retail  stores."  After  raids  and 


• National  Institute  of  Justice  publish- 
re  anew  resource  manual  on  computer 
cram.  It  a aimed  at  helping  sudden, 
security  experts  and  cranmal  jusace 
aynm-MMi  cgrbAmi  vBtinm  canpotcf 
ancon,  iwiurting  piracy.  Dk.  L 1989. 

• Singapore  poire  red  BSA  rad  five 
targets  of  —petted  software  piracy. 

• BSA  snaouarea  it  wffl  take  legal  ac- 
!k»  atpumt  a Hong  Kong  piracy  syixh- 
cate  Um  allegedly  coped  $50  million 
worth  of  programs  and  manuals.  Norn. 

izisrn 


lawsuits  against  six  maior  retail  outlets 
and  ae  uncovering  of  an  international 
mail-order  operation,  be  says,  the  pirated 
software  trade  has  really  dried  up. 

By  working  doaefy  with  international 
government*  and  trade  aasooabons  to 
avoid  "being  sere  sa  American*  coming  in 
and  telling  people  bow  to  behave."  Phil- 
lip* says  he  is  confident  that  interna  taonai 
psracy  will  canriaue  to  be  stymied. 

To  think  that  piracy  mil  be  completely 
Afewatwi  is  unrealistic  A more  attain- 
able goal  is  to  have  it  perceived  as  nsky 
conduct, 

“We  want  to  get  to  the  point''  Phillips 
says,  “where  stealing  software  from  the 
store  and  copying  it  are  seen  as  the  same 
thing.”  • 
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Memo:  Computer  Viruses 
and  Personal  Computers 

Sandra  Bogenholm,  CSSO 
DOE  Center  for  Computer 
Security 

This  was  originally  written  for 
the  N-4  group  at  Los  Alamos 
National  Laboratory.  CSSOs  may 
wish  to  edit  it  to  fit  local 
conditions  and  use  it  to  educate 
personal  computer  users  at  their 
sites. 

As  a personal  computer  user  you 
are  responsible  for  certain  data 
protection  functions  on  your  PC 
or  workstation  system  that  are 
handled  automatically  by  the 
system  manager  of  a mainframe 
system.  These  functions  include 
providing  physical  security  for 
the  system  and  media,  providing 
adequate  backup  for  all  software 
and  data,  ensuring  that  only 
information  appropriate  to  the 
authonzed  levels  of  classification 
and  category  is  stored  or 
processed  on  your  system,  and 
ensuring  that  infected  software  is 
not  run  on  your  computer. 

Recently,  many  viruses  (or  related 
code)  have  been  infecting 
computer  systems  around  the 
laboratory.  A virus  is  a "self- 
propagating  Trojan  horse, 
composed  of  a mission 
component,  a trigger  component, 
and  a self-propagating 
component."  * A virus  can  cause 
a number  of  benign  or  serious 
problems  anything  from  a 
message  on  the  screen,  to  data 
alteration,  data  loss,  etc. 

The  most  likely  entry  point  for  a 
virus  is  at  the  microcomputer 
level.  From  there  it  can  spread 
to  other  micro  or  mainframe 
computers  to  which  the 
microcomputer  is  networked  or 
with  which  you  share  media.  As 
a PC  user,  you  are  our  most 


important  line  of  defense  against 
a costly  and  embarrassing  virus 
infection.  By  keeping  your  system 
and  media  free  from  viral 
infection,  you  protect  not  only 
yourself  but  also  users  with 
whom  you  share  files.  Most  of 
us  share  files  with  the  office 
word  processors  and  other  staff, 
so  let’s  practice  "Safe 
Computing."  If  all  of  us  take  the 
responsibility  to  protect  our  own 
systems  and  media,  we  will  all 
be  protected. 

Attached  is  a list  of  guidelines  to 
help  you  minimize  the  likelihood 
of  a virus  infection,  diagnose  the 
presence  of  a virus,  and  respond 
in  the  event  of  an  infection.  A 
Telephone  Call  Checklist  (similar 
to  a bomb  threat  telephone 
checklist)  is  included  to  help 
you  conduct  an  interview  with 
anyone  phoning  to  threaten  or 
inform  you  of  a virus  attack. 
Please  copy  the  checklist  and 
keep  it  in  your  phone  book  along 
with  the  bomb  threat  instructions. 


Computer  Virus  Guidelines 

Protection  from  viral  infection 
includes  knowing  your  software 
sources  and  limiting  sources  to 
commercial  ones  whenever 
possible.  It  also  includes  limiting 
access  to  your  computer  and  its 
media.  Recovery  from  infection 
is  facilitated  by  having  backups 
of  the  operating  system, 
application  programs,  and  data 
files  and  by  your  keeping  several 
previous  backups  so  that  you  are 
sure  you  can  go  back  to  a point 
before  the  infection  to  reconstruct 
the  system  and  data.  Finally, 
knowing  your  system  and  running 
virus  detection  programs  helps 
you  monitor  your  system  to 
ensure  contamination-free  files 
and  system. 


Preventative  and  Damage  Control 
Measures 

A.  Backup 

Make  frequent  data  file 
backups  and  store  the  diskettes 
or  other  media  in  a safe  location 
(ideally  in  a different  office  and 
building  from  your  computer). 
Files  that  would  be  difficult  or 
time-consuming  to  recreate  should 
be  backed  up  most  often.  Practice 
recovering  your  files  from  the 
backups.  There  are  commercial 
software  programs  that  can 
quickly  back  up  your  hard  disk. 
Save  the  backup  diskette  sets  of 
critical  or  hard-to-replace  files  for 
at  least  a year  unless  they 
become  obsolete  before  then. 

Always  make  a backup  or 
working  copy  of  application 
software;  never  run  directly  from 
the  distribution  disk.  If  you  have 
problems  with  your  disk, 
computer,  or  a virus,  you  can 
reinstall  the  software  after  the 
problem  is  corrected. 

Never  boot  your  system  with 
the  original  operating  system 
diskettes.  Make  backup  copies 
before  you  install  the  system 
software,  and  use  them  for 
intallation.  Write-protect  and  store 
the  original  diskettes  in  a sale 
location.  Subsequently,  boot 
from  the  hard  disk  or  from  your 
backup  copies.  Also,  never  add 
data  or  programs  to  the  original 
system  diskettes. 

The  best  possible  protection 
against  virus  infection  damage  or 
other  disk  problems  is  a correct 
and  thorough  backup  procedure. 
At  the  very  least,  anyone  using  a 
PC  (Mac  or  IBM,  etc.)  should 
make  backup  copies  on 
removable  disks  of  all  data  files 
and  application  programs. 

B,  Software 

1.  Unauthorized  or 
Noncommercial  Software 


Repnnted  with  permission,  from  the  August  1989  issue  of  Center  for  Computer  Security  News. 
Department  of  Energy,  Center  for  Computer  Security. 
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Do  not  bring  ANY 
unauthorized  code  (software)  into 
the  workplace  especially  software 
downloaded  from  public  bulletin 
boards.  Be  suspicious  of  any 
software  or  software  media 
supplied  by  friends.  It  is 
recommended  that  software  be 
purchased  through  normal 
procurement  channels  or  that  it 
be  reviewed  by  knowledgeable 
programming/security  personnel. 

Do  NOT  use  shareware  when 
a commercial  product  is  available. 
Try  to  obtain  source  code 
whenever  possible. 

If  you  believe  it  is  necessary 
to  use  noncommercial  software, 
limit  your  sources  to  the  most 
established,  reliable  ones.  A 
colleague  down  the  hall  may  or 
may  not  be  a reliable  source 
because  he  is  unlikely  to  have 
checked  the  software  thoroughly 
(unless  he  wrote  the  application 
himself),  even  if  he  has  used  it 
for  some  time.  (Remember, 
some  viruses  have  a time  bomb 
or  usage  count  detonator 
embedded  in  them). 

If  you  must  use 
noncommercial  software, 

- Try  to  get  the  source  code  (not 
just  the  executable  code).  - Have 
an  experienced 

programmer/security  person  do  a 
security  review  of  the  code  and 
investigate  anything  suspicious.  - 
Ask  for  software  design 
documentation  and  reviews  if 
appropriate.  - Do  anything  else 
you  can  to  ensure  the  safety  of 
the  code. 

Beware  of  files  you  create  on 
your  home  computer  and  bring  to 
work.  Has  someone  used  the 
home  computer  and  imported  a 
virus?  Family  members  may 
have  added  infected  shareware  or 
games  obtained  from  friends  or 
bulletin  boards.  Or  the 
neighborhood  whiz  kid  may  have 
planted  an  original  or  copied 
virus  on  your  machine. 


2.  Software  Development 

Assign  sensitive  software 
development  tasks  to  trusted 
persons  or  subject  all  software  to 
independent  review  before  it  is 
installed. 

Use  a two-person  rule  for 
software  and  hardware  design, 
implementation,  testing,  and 
review.  Better  yet,  encourage  the 
use  of  good  software  engineering 
practices  and  hold  design  reviews, 
code  walk-throughs,  etc.  Keep 
development  and  production 
isolated  from  each  other. 

Associate  each  copy  or 
module  of  software  with  an 
individual  who  is  responsible  for 
it. 

3.  Specific  Systems 

When  you  initially  install 
your  operating  system  software 
(DOS  or  MS-DOS  users), 
examine  the  COMMAND.  COM 
file.  Write  down  its  size, 
creation  date  and  creation  time. 
Periodically  reexamine 
COMMAND.COM  to  see  if  any 
changes  in  size,  date,  or  time 
have  occurred.  Such  changes 
may  mean  that  a virus  has 
corrupted  the  file.  If  you  note 
unexplainable  changes,  rebuild 
DOS  with  the  "SYS"  command. 

All  file  servers  or  networked 
Sun,  Apollo,  and  other  computers 
running  Unix  should  have 
anonymous  FTP  disabled  and  the 
sendmail  utility  installed  without 
debug.  You  should  recheck  these 
after  major  operating  system 
upgrades. 

Check  any  multiuser  system  to 
ensure  that  all  anonymous,  debug, 
dealer  service,  and  other  general 
user  identifiers,  passwords,  and 
accounts  are  disabled.  These 
should  also  be  checked  after  each 
operating  system  upgrade. 

There  are  programs  available 


for  both  Macintoshes  and  IBM 
PCs  that  can  be  run  periodically 
to  look  for  known  virus 
behaviors.  You  should  run  such 
a program  at  least  once  a month, 
but  preferably  more  often.  Ask 
your  CSSO  or  computer  security 
organization  about  such  detection 
programs. 

4.  Write  Protection  and  File 
Locking 

If  your  operating  system 
supports  locking  files  to  prevent 
changes  (easy  to  do  for 
Macintosh,  Unix,  and  VMS),  set 
that  protection  on  all  files  that 
you  seldom  change.  Although  a 
virus  can  get  round  this,  many 
have  not  been  written  to 
anticipate  locked  files  so  some 
protection  is  provided  by  taking 
this  precaution. 

When  you  obtain  new 
software,  write-protect  the 
distribution  disk  or  tape  before 
making  a backup  or  working 
copy  or  installing  the  software  on 
your  hard-disk.  Just  inserting  a 
disk  in  an  infected  system  can  be 
enough  to  corrupt  the  diskette. 

In  fact,  it  is  always  a good  idea 
to  use  write-protected  disks 
unless  you  know  you  will  need  to 
write  to  a disk. 

When  you  use  commercial 
software,  try  to  avoid  packages 
that  use  copy  protection.  This 
allows  you  to  follow  the 
preceding  suggestion. 

Applications  and  data  can  be  kept 
on  write-protected  removable 
media  (cartridge  drives  or 
floppies)  and  inserted  into  a 
workstation  only  when  needed. 

5.  Miscellaneous 

Test  every  unknown  program 
before  system-wide  release 
(preferably  on  an  isolated 
system). 

Use  password  security  if 
available. 
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Report  any  unauthorized  use 
of  your  system  to  your  CSSO. 

If  you  believe  your  system 
has  high  vulnerability  to  a virus, 
contact  your  CSSO  or  computer 
security  organization.  They  may 
be  able  to  aid  you  in  the  use  of 
virus  detection  software. 

Make  it  a practice  to  power  down 
your  microcomputer  overnight, 
and  do  not  leave  diskettes  in  the 
disk  drives  overnight.  You  may 
wish  to  install  a locking  device 
on  the  power  switch  to  prevent 
unauthorized  access  to  your 
computer. 

Have  standard  recovery 
procedures  in  place.  Now  is  a 
good  time  to  develop  a 
contingency  plan. 

Diagnosing  the  Presence  of  a 
Virus 

The  best  way  to  detect  the 
presence  of  a computer  virus  is 
to  be  as  familiar  as  possible  with 
the  way  your  computer  runs  in 
daily  operation.  In  addition,  look 
for  the  following  indications  of 
system  contamination: 

Program  or  data  files 
mysteriously  disappear. 

Unusual  messages  appear  on 
the  screen.  Some  viruses  even 
announce  that  your  system  has 
been  infected. 

An  unusual  number  of 
program  or  system  crashes  or 
print  errors  occur. 

Sudden,  unexplainable 
reductions  in  system  memory  or 
disk  space  occur. 

Your  computer  seems  to  run 
more  slowly  than  normal. 

Program  loads  take  longer 
than  normal. 

An  unusual  number  of  disk 
accesses  occur. 


Disk  drive  access  lights  come 
on  for  no  apparent  reason. 

An  executable  file, 
particularly  COMMAND.  COM, 
changes  in  size. 

Unexplainable  hidden  files 
appear.  IBM  PC-DOS  V4.0  has 
three  hidden  files,  earlier  versions 
have  two.  But  be  aware  that 
some  application  software  does 
create  legitimate  hidden  files. 

On  a Macintosh  some  icons 
(in  particular,  those  representing 
the  Scrapbook  and  Notebook) 
change  in  appearance. 

Responding  if  You  think  You 
have  a Virus 

Record  all  you  can  about  the 
circumstances  and  details. 

If  a strange  message  appears 
on  the  screen,  record  the  EXACT 
content  of  the  message. 

Do  nothing  irrevocable.  Do 
not  reformat  the  disk.  Do  not 
turn  the  system  power  off. 

Ask  yourself:  Is  my  computer 
attached  in  any  way  to  another 
computer?  If  so,  should  this 
connection  be  broken  until  the 
problem  is  solved? 

Try  to  isolate  the  hardware 
and  software  that  you  suspect  is 
infected. 

Contact  your  CSSO  for  help. 

If  the  CSSO  is  not  available, 
contact  your  supervisor  or 
computer  security  organization, 
and  noufy  the  CSSO  as  soon  as 
possible. 

Prevent  the  transmission  of 
any  suspected  software  across  any 
network. 

Try  to  establish  the  source  by 
thinking  about  where  your 
software  came  from,  who  has 
been  using  your  machine,  etc. 


Don’t  my  suspicious  software 
on  another  system  use  a 
completely  isolated  and  cleansed 
system  and  only  if  you  know 
what  you  are  doing. 

The  advice  in  this  article  is 
based  in  part  on  information 
kindly  offered  by  the  Kansas  City 
Computer  Virus  Team  at  Allied 
Signal,  Inc,,  R.  K.  Wallace,  X- 
DO,  Los  Alamos  National 
Laboratory  and  Jared  Dreicer, 
DOE  Center  for  Computer 
Security,  LANL, 

Computer  Virus  Telephone 
Checklist 

Time 

Date 

L Ask  the  caller’s  name. 


2.  Try  to  determine  if  the  caller 
is  offsite  or  within  the 
organization. 


3.  Try  to  get  another  person  on 
the  line  with  you. 

4.  Ask  what  computer  system  or 
what  type  of  computer  it  will 
affect. 


5.  If  the  caller  says  it  is  a virus, 
ask  the  following  quesuons: 

A.  Where  is  the  source  of 
attack  for  the  virus-network, 
phone  port,  imported  software, 
etc. 


B.  What  will  the  virus  do 
to  show  its  presence:  what  is  its 
ultimate  effect? 


C.  Why  is  the  virus  here? 


D.  What  will  disarm  the  virus? 


6.  Note  background  noises  on  the 
line-music,  traffic,  motors,  or 
unusual  sounds. 


7.  Think  about  the  caller 

Male  

Female 

Any  accent  or  speech 
impediment? 


Anything  familiar  or 
unusual? 


8.  When  the  call  is  completed: 

A.  Call  your  CSSO  or 
computer  security  organization. 

B.  If  appropriate,  call 
the  DOE  Center  for  Computer 
Security  (FTS)  843-0444  or  (505) 
667-0444. 


C.  Tell  your  supervisor 
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WRING  AWARD  LSCTURi 


Reflections  on  Trusting  Trust 

To  what  extent  should  one  trust  a statement  that  a program  is  free  of  Trojan 
horses?  Perhaps  it  is  more  important  to  trust  the  people  who  wrote  the 
software . 


Originally  published  in  Communications  of  the  ACM , Vol  7,  Number  8,  August  1984. 
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INTRODUCTION 

I thank  the  ACM  for  this  award.  I can't  help  but  feel 
that  I am  receiving  this  honor  for  timing  and  serendip- 
ity as  much  as  technical  merit.  UNIX1  swept  into  popu- 
larity with  an  industry-wide  change  from  central  main- 
frames to  autonomous  minis.  I suspect  that  Daniel  Bob- 
row  [l]  wouid  be  here  instead  of  me  if  he  could  not 
afford  a PDP-10  and  had  had  to  "settle"  for  a PDP-11. 
Moreover,  the  current  state  of  UNIX  is  the  result  of  the 
laDors  of  a iarge  number  of  people. 

There  is  an  old  adage.  “Dance  with  the  one  that 
brought  you.”  which  means  that  I should  talk  about 
UNIX.  I have  not  worked  on  mainstream  UNIX  in  many 
years,  yet  I continue  to  get  undeserved  credit  for  the 
work  of  others.  Therefore.  ! am  not  going  to  talk  about 
UNIX,  but  I want  to  thank  everyone  who  has  contrib- 
uted. 

That  brings  me  to  Dennis  Ritchie.  Our  collaboration 
has  been  a thing  of  beauty.  In  the  ten  years  that  we 
have  worked  together.  I can  recall  only  one  case  of 
miscoordination  of  worn.  On  that  occasion.  I discovered 
that  we  ooth  had  written  the  same  20-line  assembly 
language  program.  I compared  the  sources  and  was  as- 
tounded to  find  that  they  matched  character-for-char- 
acter.  The  result  of  our  work  together  has  been  far 
greater  than  the  work  that  we  each  contributed. 

1 am  a programmer.  On  my  1040  form,  that  is  what  I 
put  down  as  my  occupation.  As  a programmer.  I write 


1 UNIX  is  a traaemaric  of  AT&T  Bell  Laooraiones. 
C 1984  0001  -0782  / 34  / 0800— <9761  73C 


programs,  I wouid  like  to  present  to  you  the  cutest 
program  I ever  wrote.  I will  do  this  in  three  stages  and 
try  to  bring  it  together  at  the  end. 

STAGE  I 

In  college,  before  video  games,  we  wouid  amuse  our- 
selves by  posing  programming  exercises.  One  of  the 
favorites  was  to  write  the  shortest  self-reproducing  pro- 
gram. Since  this  is  an  exercise  divorced  from  reaiitv. 
the  usual  vehicle  was  FORTRAN.  Actually,  FORTRAN 
was  the  language  of  choice  for  the  same  reason  that 
three-legged  races  are  popular. 

More  precisely  stated,  the  problem  is  to  write  a 
source  program  that,  when  compiled  and  executed,  will 
produce  as  output  an  exact  copy  of  its  source.  If  you 
have  never  done  this.  I urge  you  to  try  it  on  your  own. 
The  discovery  of  how  to  do  it  is  a revelation  that  far 
surpasses  any  benefit  obtained  by  being  told  how  to  do 
it.  The  pari  about  “shortest”  was  just  an  incentive  to 
demonstrate  skill  and  determine  a winner. 

Figure  I shows  a seif-reproducing  program  in  the  C3 
programming  language.  (The  punst  will  note  that  the 
program  is  not  precisely  a seif-reproducing  program, 
but  will  produce  a self-reproducing  program.)  This  en- 
try is  much  too  large  to  win  a prize,  but  it  demonstrates 
the  technique  and  has  two  important  properties  that  I 
need  to  complete  my  story:  1)  This  program  can  be 
easily  written  by  another  program.  2)  This  program  can 
contain  an  arbitrary  amount  of  excess  baggage  that  will 
be  reproduced  along  with  the  main  algorithm.  In  the 
example,  even  the  comment  is  reproduced. 
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cfiar  5(  ] * I 

'V'. 

'O'. 

'Vi'. 

'I'. 

'Vj\ 

'Vi'. 

7\ 

'Vi'. 

(213  lines  deleted) 
0 


/* 

« The  string  s is  a 
•>  representation  of  the  body 
a of  this  program  from  0' 

« to  the  end. 

•/ 

main!  ) 

I 

mt  i; 

pnntf(‘char\ts(  ] =»  |Vi*); 
fbr(/«0;  *{/]:  /+-♦») 

pnntf(°Y%ds  VT.  s[/]); 
printfC^s*.  s)° 

I 

Here  are  some  simple  transliterations  to  allow 
a non-C  programmer  to  read  this  code. 

=*  assignment 

==  equal  to  EQ. 

!=  not  eaual  to  NE. 

-t--r  increment 

x single  character  constant 
*xxx’  multiple  character  smng 
%d  format  to  convert  to  oeamal 

9/os  format  to  convert  to  stnng 

V tap  character 

Vi  newline  character 

FIGURE  1. 

STAGE  II 

The  C compiler  is  written  in  C.  What  I am  about  to 
describe  is  one  of  many  “chicken  and  egg”  problems 
that  arise  when  compilers  are  written  in  their  own  lan- 
guage. In  this  case,  I will  use  a specific  example  from 
the  C compiler. 

C allows  a string  construct  to  specify  an  initialized 
character  array  The  individual  characters  in  the  stnng 
can  be  escaped  to  represent  unpnntable  characters.  For 
example. 

“Hello  world\n” 

represents  a string  with  the  character  “\n,"  representing 
the  new  line  character. 

Figure  2.1  is  an  idealization  of  the  code  in  the  C 
compiler  that  interprets  the  character  escape  sequence. 
This  is  an  amazing  piece  of  code.  It  “knows”  in  a com- 
pletely portable  way  what  character  code  is  compiled 
for  a new  line  in  any  character  set.  The  act  of  knowing 


then  allows  it  to  recompile  itself,  thus  perpetuating  the 
knowledge. 

Suppose  we  wish  to  alter  the  C compiler  to  include 
the  sequence  “\y”  to  represent  the  vertical  tab  charac- 
ter. The  extension  to  Figure  2.1  is  obvious  and  is  pre- 
sented in  Figure  2.2.  We  then  recompile  the  C com- 
piler. but  we  get  a diagnostic.  Obviously,  since  the  bi- 
nary version  of  the  compiler  does  not  know  about 
the  source  is  not  legal  C.  We  must  “train”  the  compiler. 
After  it  “knows”  what  “\v”  means,  then  our  new 
change  will  become  legal  C.  We  look  up  on  an  ASCII 
chart  that  a vertical  tab  is  decimal  11.  We  alter  our 
source  to  look  like  Figure  2.3.  Now  the  old  compiler 
accepts  the  new  source.  We  install  the  resulting  binary 
as  the  new  official  C compiler  and  now  we  can  write 
the  portable  version  the  way  we  had  it  in  Figure  2.2. 

This  is  a deep  concept.  It  is  as  close  to  a “learning” 
program  as  1 have  seen.  You  simply  tell  it  once,  then 
you  can  use  this  self-referencing  definition. 

STAGE  ID 

Again,  in  the  C compiler.  Figure  3.1  represents  the  high 
level  control  of  the  C compiler  where  the  routine  "com- 


e » next(  ); 
if(c  !»  '\\') 

retum(e); 
c * nextf  ); 
if(C  — AY) 

retum('W'); 
rf(c  ==  'n') 

retum('Vi'); 


FIGURE  2.2. 


c = next(  ); 
if(C  !=  AY) 

retum(c); 
c = next(  ); 
if(c  ==  AY) 

retum('W'); 
rffc  =-  'n') 

retum('\n'); 
if(c  =-  V) 

return!  Av'); 


FIGURE  2.1. 


c - next!  ); 
if(c  !-  AY) 

returryc); 
c = next(  ); 
if(c  « AY) 

return!  AY); 
if(c  ==  'rt') 

return!  A n'), 
lf(C  ==•  'v') 

return!  1 1 ), 


FIGURE  2.3. 
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pile”  is  called  to  compile  the  next  line  of  source.  Figure 
3.2  shows  a simple  modification  to  the  compiler  that 
will  deliberately  miscompile  source  whenever  a partic- 
ular pattern  is  matched.  If  this  were  not  deliberate,  it 
would  be  called  a compiler  “bug."  Since  it  is  deliberate, 
it  should  be  called  a “Trojan  horse." 

The  actual  bug  I planted  in  the  compiler  would 
match  code  in  the  UNIX  “login"  command.  The  re- 
placement code  would  miscompile  the  login  command 
so  that  it  would  accept  either  the  intended  encrypted 
password  or  a particular  known  password.  Thus  if  this 
code  were  installed  in  binary  and  the  binary  were  used 
to  compile  the  login  command.  I could  log  into  that 
system  as  any  user. 

Such  blatant  code  would  not  go  undetected  for  long. 
Even  the  most  casual  perusal  of  the  source  of  the  C 
compiler  would  raise  suspicions. 

The  final  step  is  represented  in  Figure  3.3.  This  sim- 
ply adds  a second  Trojan  horse  to  the  one  that  already 
exists.  The  second  pattern  is  aimed  at  the  C compiler. 
The  replacement  code  is  a Stage  I self-reproducing  pro- 
gram that  inserts  both  Trojan  horses  into  the  compiler. 
This  requires  a learning  phase  as  in  the  Stage  H exam- 
ple. First  we  compile  the  modified  source  with  the  nor- 
mal C compiler  to  produce  a bugged  binary.  We  install 
this  binary  as  the  official  C.  We  can  now  remove  the 
bugs  from  the  source  of  the  compiler  and  the  new  bi- 
nary will  reinsert  the  bugs  whenever  it  is  compiled.  Of 
course,  the  login  command  will  remain  bugged  with  no 
trace  in  source  anywhere. 


compiler) 

cflar 

1 

1 

FIGURE  3.1. 

compilers) 
c ttar  -s; 

i 

i 

iffmatcnis.  "pattern')) ) 
compneTbug'); 
return: 

1 

1 

FIGURE  3.2. 

compile*  s> 

cnar  -s: 

l 

iffmatons.  "partemf))  | 
compile  C&ugT): 

return: 

l 

iffmatcm,  "pattern  2*))  1 
compile  ("bug  2*); 
return: 

1 

1 

FIGURE  3.3. 


MORAL 

The  moral  is  obvious.  You  can’t  trust  code  that  you  did 
not  totally  create  yourself.  (Especially  code  from  com- 
panies that  employ  people  like  me.)  No  amount  of 
source-level  verification  or  scrutiny  will  protect  you 
from  using  untrusted  code.  In  demonstrating  the  possi- 
bility of  this  kind  of  attack.  I picked  on  the  C compiler. 

I could  have  picked  on  any  program-handling  program 
such  as  an  assembler,  a loader,  or  even  hardware  mi- 
crocode. As  the  level  of  program  gets  lower,  these  bugs 
will  be  harder  and  harder  to  detect.  A well-installed 
microcode  bug  will  be  almost  impossible  to  detect. 

After  trying  to  convince  you  that  I cannot  be  trusted, 

I wish  to  moralize.  I would  like  to  criticize  the  press  in 
its  handling  of  the  “hackers,"  the  414  gang,  the  Dalton 
gang,  etc  The  acts  performed  by  these  kids  are  vandal- 
ism at  best  and  probably  trespass  and  theft  at  worst.  It 
is  only  the  inadequacy  of  the  criminal  code  that  saves 
the  hackers  from  very  serious  prosecution.  The  compa- 
nies that  are  vulnerable  to  this  activity,  (and  most  large 
companies  are  very  vulnerable)  are  pressing  hard  to 
update  the  criminal  code.  Unauthorized  access  to  com- 
puter systems  is  already  a serious  cnme  in  a few  states 
and  is  currently  being  addressed  in  many  more  state 
legislatures  as  well  as  Congress. 

There  is  an  explosive  situation  brewing.  On  the  one 
hand,  the  press,  television,  and  movies  make  heros  of 
vandals  by  calling  them  whiz  kids.  On  the  other  hand, 
the  acts  performed  by  these  kids  will  soon  be  punisha- 
ble by  years  in  prison. 

I have  watched  kids  testifying  before  Congress.  It  is 
dear  that  they  are  completely  unaware  of  the  serious- 
ness of  their  acts.  There  is  obviously  a cultural  gap.  The 
act  of  breaking  into  a computer  system  has  to  have  the 
same  social  stigma  as  breaking  into  a neighbor's  house. 

It  snouid  not  matter  that  the  neignbor's  door  is  un- 
locked. The  press  must  learn  that  misguiaea  use  of  a 
computer  ls  no  more  amazing  than  drunk  driving  of  an 
automobile. 

Acknowledgment . I first  read  of  the  possibility  of  such 
a Trojan  horse  in  an  Air  Force  cntique  [4]  of  the  secu- 
rity of  an  early  implementation  of  Multics.  I cannot  find 
a more  specific  reference  to  this  document,  I would 
appreciate  it  if  anyone  who  can  supply  this  reference 
would  let  me  know. 
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Late  in  the  evening  of  2 No- 
vember 1988,  someone  re- 
leased a "worm"  program  into 
the  ARPAnet  The  program  expro- 
priated the  resources  of  each  in- 
vaded computer  to  generate  rep- 
licas of  itself  on  other  computers,  but  did  no  apparent 
damage.  Within  hours,  it  had  spread  to  several  thousand 
computers  attached  to  the  worldwide  Research  Internet 
Computers  infested  with  the  worm  were  soon  labor- 
ing under  a huge  load  of  programs  that  looked  like 
innocuous  "shell"  programs  (command  interpreters). 
Attempts  to  kill  these  programs  were  ineffective:  new 
copies  would  appear  from  Internet  connections  as  fast  as 
old  copies  were  deleted.  Many  systems  had  to  be  shut 
down  and  the  security  loopholes  closed  before  they 
could  be  restarted  on  the  network  without  reinfestation. 

Fortuitously,  the  annual  meeting  of  Unix  experts 
opened  at  Berkeley  on  the  morning  of  November  3.  They 
quickly  went  to  work  to  capture  and  dissect  the  worm. 
By  that  evening,  they  had  distributed  system  fixes  to 
close  all  the  security  loopholes  used  by  the  worm  to 
infest  new  systems.  By  the  morning  of  November  4, 
teams  at  mu,  Berkeley,  and  other  institutions  had  decom- 
piled the  worm  code  and  examined  the  worm's  structure 
in  the  programming  language  C.  They  were  able  to 
confirm  that  the  worm  did  not  delete  or  modify  files 
already  in  a computer.  It  did  not  install  Trojan  horses, 
exploit  superuser  privileges,  or  transmit  passwords  it 
had  deciphered.  It  propagated  only  by  the  network 
protocols  tcp/ip,  and  it  infested  computers  running 
Berkelev  UNIX  but  not  AT&T  System  V UNIX.  As  the 
community  of  users  breathed  a collective  sigh  of  relief, 
system  administrators  installed  the  fixes,  purged  all 
copies  of  the  worm,  and  restarted  the  downed  systems. 
Most  hosts  were  reconnected  to  the  Internet  bv  Novem- 
ber 6,  but  the  worm's  effect  lingered:  a few  hosts  were 
stall  disconnected  as  late  as  November  10,  and  mail 
backlogs  did  not  dear  until  November  12. 

The  worm's  fast  and  massive  infestation  was  so 
portentous  that  the  New  York  Times  ran  updates  on  page 
one  for  a week.  The  'Nail  Street  [oumal  and  usa  Today  gave 
it  front-page  coverage.  It  was  the  subject  of  two  articles  in 
Science  magazine  (1,  2).  It  was  covered  by  the  wire 
services,  the  news  shows,  and  the  talk  shows.  These 
accounts  said  that  over  6,000  computers  were  infested, 
but  later  estimates  put  the  actual  number  between  3,000 
and  4,000,  about  5%  of  those  attached  to  the  Internet. 

On  November  5 the  New  York  Times  broke  the  storv 
that  the  alleged  culprit  was  Robert  T.  Moms,  a Cornell 
graduate  student  and  son  of  a weil-known  computer 
security  expert  who  is  the  chief  scientist  at  the  National 
Computer  Security  Center.  A friend  reportedly  said  that 
Moms  intended  no  disruption;  the  worm  was  supposed 
to  propagate  slowiv,  but  a design  error  made  it  unexpect- 
edly prolific.  When  he  realized  what  was  happening. 
Moms  had  a inend  post  on  an  electronic  bulletin  board 
instructions  telling  how  to  disable  the  worm — but  no  one 
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could  access  them  because  all  af- 
fected computers  were  down.  As 
of  February  1989,  no  indictments 
had  been  filed  as  authonties  pon- 
dered legal  questions.  Morris 
himself  was  silent  throughout. 

The  worm's  author  went  to  great  lengths  to  con- 
found the  discovery  and  analysis  of  it,  a delaying  tactic 
that  permitted  the  massive  infestation.  By  early  Decem- 
ber 1988,  Eugene  Spafford  of  Purdue  (3),  Donn  Seeiev  of 


How  the  worm  worked 

The  Internet  worm  of  November  1 988  was  a program  that 
invaded  Sun  3 and  vax  eomputers  running  versions  of  the 
Berkeley  4.3  Unix  operating  system  containing  the  tcp/ip  Internet 
protocols.  Its  sole  purpose  was  to  enter  new  machines  by 
bypassing  authentication  procedures  and  to  propagate  new 
copies  of  itself.  It  was  prolific,  generating  on  the  order  of 
hundreds  of  thousands  of  copies  among  several  thousand 
machines  nationwide,  it  did  not  destroy  information,  give  away 
passwords,  or  implant  Troian  horses  for  later  damage. 

A new  worm  oegan  life  by  building  a list  of  remote  machines 
to  attack.  It  made  its  selections  from  the  tables  oecianng  which 
other  machines  were  trusted  by  its  current  host  from  users 
maiWorwarding  files,  from  tables  by  which  users  give  themserves 
permission  for  access  to  remote  accounts,  and  from  a program 
that  reports  the  status  of  network  connections.  For  each  of  these 
potential  new  hosts,  it  attempted  entry  by  a variety  of  means: 
masquerading  as  a user  by  logging  into  an  account  after  cracking 
its  password;  exploiting  a bug  in  the  finger  protocol,  which  reports 
the  whereabouts  of  a remote  user  and  exploiting  a trapdoor  in 
the  debug  oooon  of  the  remote  process  that  receives  and  sends 
maii.  In  parallel  with  attacks  on  new  hosts,  the  worm  uncertooK  to 
guess  the  passwords  of  user  accounts  in  its  current  host  It  first 
tned  the  account  name  and  simple  oermutaoons  of  it.  then  a list 
of  432  Puiit-m  Dassworas.  and  finally  all  the  words  from  the  ocai 
dictionary.  An  undetected  worm  could  have  spent  manv  oavs  at 
these  password-cracwng  attemots. 

If  any  of  its  attacks  on  new  hosts  worxec.  the  worm  would 
find  rtseif  in  communication  with  a "shell”  program— a commana 
interpreter— on  the  remote  machine.  It  fee  that  sneil  a 99-iine 
bootstrap  program,  together  with  commands  to  compile  and 
execute  it  and  then  broke  the  connection.  If  the  bootstrap 
program  started  successfully,  it  would  call  back  the  parent  worm 
within  1 20  seconds.  The  parent  worm  copied  over  enconereo 
files  containing  the  full  worm  code,  which  was  compiled  from  a 
G-program  of  over  3,000  lines.  The  parent  worm  then  issued 
commands  to  construct  a new  worm  from  the  enciphered  pieces 
and  stan  it 

The  worm  also  made  attemots  at  population  control,  looking 
for  other  worms  in  the  same  host  and  negotiating  with  them  wmch 
would  terminate.  However,  a worm  that  agreed  to  terminate 
would  first  attack  marry  hosts  before  comoieong  its  oart  of  the 
bargain— saving  the  overall  birthrate  nlgher  man  the  oeathrate. 
Moreover,  one  in  seven  worms  aeciareo  itserf  irnmonai  ana 
entirely  bypassed  any  paroa canon  in  poouiauon  control. 

The  worm  s author  tooK  considerable  oains  to  camouflage  it. 
The  mam  worm  code  was  enciphered  and  sent  to  the  remote 
host  only  when  the  oootstrao  was  known  to  0e  operating  there  as 
an  accomplice.  The  new  worm  left  no  traces  in  the  tile  system:  it 
coded  all  its  files  into  memory  and  deleted  them  from  a system  s 
directories.  The  worm  disabled  the  system  function  that  Droauces 
"memory  dumos " in  case  of  error,  and  it  keot  ail  character  stnngs 
enaohered  so  that  in  case  a memory  dump  were  oOtained 
anyway,  it  would  be  meaningless.  The  worm  program  gave  itself 
a name  that  made  it  appear  as  an  innocuous  shell  to  the  Drogram 
that  lists  orocesses  in  a system,  and  it  frequently  changed  its 
process  identifier 
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Utah  (4),  and  Mark  Eichin  and  Jon  Rochlis  of  mit  (5)  had 
published  technical  reports  about  the  decompiled  worm 
that  described  the  modes  of  infestation  and  the  methods 
of  camouflage.  They  .were  impressed  by  the  worm's 
battery  of  attacks,  saying  that,  despite  errors  in  the 
source  program,  the  code  was  competently  done.  The 
National  Computer  Security  Center  requested  them  and 
others  not  to  publish  the  decompiled  code,  fearing  that 
troublemakers  might  reuse  the  code  and  modify  it  for 
destructive  acts.  Seeley  replied  that  the  question  is  moot 
because  the  worm  published  itself  in  thousands  of  com- 
puters. 

The  reactions  of  the  computer  science  community 
have  been  passionate.  Some  editorial  writers  report  that 
Morris  has  become  a folk  hero  among  students  and 
programmers,  who  believe  that  the  community  ought  to 
be  grateful  that  he  showed  us  weaknesses  in  our  com- 
puter networks  in  time  to  correct  them  before  someone 
launches  a malicious  attack.  The  great  majority  of  opin- 
ion, however,  seems  to  go  the  other  way.  Various 
organizations  have  issued  position  statements  decrying 
the  incident  and  calling  for  action  to  prevent  its  recur- 
rence. No  other  recent  break-in  has  provoked  similar 
outcries. 

The  organization  Computer  Professionals  for  Social 
Responsibility  issued  a statement  calling  the  release  of 
the  worm  an  irresponsible  act  and  declaring  that  no 
programmer  can  guarantee  that  a self-replicating  pro- 
gram will  have  no  unwanted  consequences.  The  state- 
ment said  that  experiments  to  demonstrate  network 
vulnerabilities  should  be  done  under  controlled  condi- 
tions with  prior  permission,  and  it  called  for  codes  of 
ethics  that  recognize  the  shared  needs  of  network  users. 
Finally,  the  statement  criticized  the  National  Computer 
Security  Center's  attempts  to  block  publication  of  the 
decompiled  worm  code  as  short-sighted  because  an 
effective  way  to  correct  widespread  secuntv  flaws  is  to 
publish  descriptions  of  those  flaws  widely. 

The  boards  of  directors  of  the  CSNET  and  bitnet 
networks  issued  a joint  statement  deploring  the  irrespon- 
sibility of  the  worm's  author  and  the  disruption  in  the 
research  community  caused  by  the  incident.  Their  state- 
ment called  for  a committee  that  would  issue  a code  of 
network  ethics  and  propose  enforcement  procedures.  It 
also  called  for  more  attention  to  ethics  in  university 
curricula.  (At  Stanford,  Helen  Nissenbaum  and  Terry 
Winograd  have  already  initiated  a seminar  that  will 
examine  just  such  questions.) 

The  advisory  panel  for  the  division  of  networking 
and  research  infrastructure  at  MSF  endorsed  the  CSNET/ 
bitnet  statement,  citing  as  unethical  any  disruption  of  the 
intended  use  of  networks,  wasting  of  resources  through 
disruption,  destruction  of  computer-based  information, 
compromising  of  privacy,  or  actions  that  make  necessary 
an  unplanned  consumption  of  resources  for  control  and 
eradication.  The  Internet  Activities  Board  has  drafted  a 
similar  statement.  The  president  of  the  Association  for 
Computing  Machinery  called  on  the  computer  science 
community  to  make  network  hygiene  a standard  practice 
(6).  A congressional  bill  introduced  in  }uiv  1988  by  Wailv 
Herger  (R-Caiif.)  and  Robert  Carr  (D-Mich.),  called  the 
Computer  Virus  Eradication  Act,  will  doubtless  reappear 
in  the  101st  Congress. 


Obviously,  all  this  interest  is  provoked  by  the  mas- 
sive scale  of  the  worm's  infestation  and  the  queasy 
feeling  that  follows  a close  call.  It  also  provides  an 
opportunity  to  review  key  areas  of  special  concern  in 
networking.  In  what  follows,  I will  comment  on  vulner- 
abilities of  open  and  closed  networks,  password  protec- 
tion, and  responsible  behavior  of  network  users. 

The  rich  imagery  of  worms  and  viruses  does  not 
promote  cool  assessments  of  what  actually  happened  or 
of  what  the  future  might  hold.  It  is  interesting  that  as 
recently  as  1982  worm  programs  were  envisaged  as 
helpful  entities  that  located  and  used  idle  workstations 
for  productive  purposes  (7);jrnost  people  no  longer  make 
this  benign  interpretation.  Some  of  the  media  reports 
have  mistakenly  called  the  invading  program  a virus 
rather  than  a worm.  A virus  is  a code  segment  that 
embeds  itself  inside  a legitimate  program  and  is  activated 
when  the  program  is;  it  then  embeds  another  copy  of 
itself  in  another  legitimate  but  uninfected  program,  and 
it  usually  inflicts  damage  (8).  Because  the  virus  is  a more 
insidious  attack,  the  mistaken  use  of  terminology  exag- 
gerated the  seriousness  of  what  had  happened.  Given 
that  the  security  weaknesses  in  the  Internet  service 
programs  have  been  repaired,  it  is  unlikeiy  that  an  attack 
against  these  specific  weaknesses  could  be  launched 
again. 

While  it  is  important  not  to  overestimate  the  serious- 
ness of  the  attack,  it  is  equally  important  not  to  under- 
estimate it  After  all,  the  worm  caused  a massive  disrup- 
tion of  service. 

We  should  acknowledge  a widespread  concern  that 
grew  out  of  this  attack;  are  networks  on  which  com- 
merce, transportation,  utilities,  national  defense,  space 
flight,  and  other  critical  activities  depend  also  vulnera- 
ble? This  concern  arises  from  an  awareness  of  the  extent 


Protecting  passwords 

The  worm  s dramatic  demonstration  of  the  weakness  of  most 
password  systems  should  prompt  a thorough  examination  in  the 
context  of  networks  of  computers.  The  following  are  oasic 
desiderata: 

—Every  account  should  be  protected  by  a password. 

—Passwords  should  be  stored  in  an  enciphered  form,  and  the  file 
containing  the  enciphered  passwords  should  not  be  publicly 
accessible  (it  is  m unix). 

— Passwords  should  be  deliberately  chosen  so  that  simple' 
attacks  cannot  work' — for  example,  they  could  induce  a 
punctuation  mark  and  a numeral. 

—Mew  passwords  should  be  checked  for  security— many 
systems  nave  (friendly!)  password  checkers  that  aitemot  to 
deapher  passwords  by  systematic  guessing,  sending  warning 
messages  to  users  if  they  are  successful. 

— To  make  extensive  guessing  expensive,  the  running  time  of  the 
password  encryption  algorithm  should  be  made  high,  on  the  order 
at  one  second.  This  can  be  achieved  by  repeatedly  enaohenng 
the  password  with  a fast  algorithm. 

— New  cost-effective  forms  of  user  authentication  should  be 
emDloyed,  inducting  devices  to  sense  personal  characteristics 
such  as  fingerprints,  retinal  patterns,  or  dynamic  signatures,  as 
well  as  magnetic  access  cards. 

—Sets  of  computers  that  are  mutually  trusting  in  the  sense  that 
login  to  one  constitutes  login  to  all  need  to  de  carefully  controlled. 
No  computer  outside  the  dedared  set  should  have 
unauthenticated  access,  and  no  computer  inside  should  grant 
access  to  an  outside  computer. 
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to  which  the  well-being  of  our  society  depends  on  the 
continued  proper  functioning  of  vast  networks  that  may 
be  fragile.  When  considering  this  question,  we  must  bear 
in  mind  that  the  Internet  is  an  open  network,  whereas 
the  others  are  closed. 

What  is  the  risk  to  an  open  network?  Because  the 
Internet  is  open  by  design,  its  computers  also  contain 
extensive  backup  systems.  Thus,  in  the  worst  case,  if  the 
worm  had  destroyed  all  the  files  in  all  the  computers  it 
invaded,  most  users  would  have  experienced  the  loss  of 
only  a day's  work.  (This  contrasts  starkly  to  the  threat 
fadng  most  PC  users,  who  because  of  the  lack  of  effective 
backup  mechanisms  stand  to  lose  years  of  work  to  a virus 
attack.)  In  addition,  users  would  certainly  lose  access  to 
their  systems  for  a day  or  more  as  the  operations  staff 
restored  information  from  backups. 

What  are  the  implications  for  other  networks?  Com- 
puters containing  proprietary  information  or  supporting 
critical  operations  are  not  generally  connected  to  the 
Internet;  the  few  exceptions  are  guarded  by  gateways 
that  enforce  strict  access  controls.  For  example,  the 
Defense  Department's  command  and  control  network 
and  nasa's  space  shuttle  network  are  designed  for  secur- 
ity and  safety;  it  is  virtually  impossible  for  a virus  or 
worm  to  enter  from  the  outside,  and  internal  mecha- 
nisms would  limit  damage  from  a virus  or  worm  im- 
planted from  the  inside.  Given  that  the  Internet  is  de- 
signed for  openness,  it  is  impossible  to  draw  conclusions 
about  dosed  networks  from  this  inddent. 

Calls  to  restrict  access  to  the  Internet  are  ill-advised. 
The  openness  of  the  Internet  is  doselv  aligned  with  a 
deepiv  held  value  of  the  sdentific  community,  the  free 
exchange  of  research  findings.  The  great  majority  of 
scientists  are  willing  to  accept  the  risk  that  their  comput- 
ers might  be  temporarily  disabled  by  an  attack,  especially 
if  a backup  system  Limits  iosses  to  a day's  work. 

The  next  area  that  calls  for  special  concern  is  pass- 
word security.  Although  trapdoors  and  other  weak- 
nesses in  Internet  protocols  have  been  dosed,  password 
protection  is  a serious  weakness  that  remains.  The  risk  is 
compounded  by  "mutually  trusting  hosts,"  a design  in 
which  a group  of  workstations  is  treated  as  a single 
system:  access  to  one  constitutes  access  to  all. 

Many  PC  systems  store  passwords  as  unenciphered 
deartext,  or  they  do  not  use  passwords  at  all.  When 
these  systems  become  part  of  a set  of  trusting  hosts,  they 
are  an  obvious  security  weakness.  Fortunately,  most 
systems  do  not  store  passwords  as  deartext.  In  UNIX,  for 
example,  the  login  procedure  takes  the  user's  password, 
enciphers  it,  and  compares  the  result  ’with  the  user's 
enciphered  entrv  in  the  password  file.  But  one  can 
discover  passwords  from  a limited  set  of  candidates  by 
enciphering  each  one  and  comparing  it  with  the  pass- 
word file  until  a match  is  found.  One  study  of  password 
files  conduded  that  anvwhere  from  8 to  30%  of  the 
passwords  were  the  literal  account  name  or  some  simple 
vanadon;  for  example,  an  account  named  "abc"  is  likeiv 
to  have  the  password  "abc,"  "bca,"  or  "abcabc"  (9).  The 
worm  program  used  a new  version  of  the  password 
enorvpdon  aigonthm  that  was  nine  times  faster  than  the 
regular  version  in  UNIX;  this  allowed  it  to  trv  manv  more 
passwords  in  a given  time  and  increased  its  chances  of 
breaking  into  at  least  one  account  on  a system.  Having 


broken  into  an  account,  the  worm  gained  easy  access  to 
that  computer's  trusted  neighbors. 

The  final  area  of  spedal  concern  is  the  behavior  of 
people  who  partidpate  in  a large  networked  community. 
Although  some  observers  say  that  the  worm  was  benign, 
most  say  that  the  disruption  of  service  and  preemption  of 
so  many  man-hours  to  analyze  the  worm  was  a major 
national  expense.  Some  observers  have  said  that  the 
worm  was  an  innocent  experiment  gone  haywire,  but 
the  experts  who  analyzed  the  code  dispute  this,  saying 
that  the  many  attack  modes,  the  immortality  of  some 
worms,  and  the  elaborate  camouflage  ail  indicate  that  the 
author  intended  the  worm  to  propagate  widely  before  it 
was  disabled.  Most  members  of  the  computer  sdence 
community  agree  that  users  must  accept  responsibility 
for  the  possible  wide-ranging  effects  of  their  actions  and 
that  users  do  not  have  license  to  access  idle  computers 
without  permission.  They  also  believe  that  the  profes- 
sional sodeties  should  take  the  lead  in  public  education 
about  the  need  for  responsible  use  of  critical  data  now 
stored  extensively  in  computers.  Similarly,  system  ad- 
ministrators have  responsibilities  to  take  steps  that  will 
minimize  the  risk  of  disruption:  they  should  not  tolerate 
trapdoors,  which  permit  access  without  authentication; 
they  should  strengthen  password  authentication  proce- 
dures to  block  guessed-password  attacks;  they  should 
isolate  their  backup  systems  from  any  Internet  connec- 
tion; and  they  should  limit  partidpation  in  mutually 
trusting  groups. 

Certainly  the  vivid  imagery  of  worms  and  viruses 
has  enabled  many  outsiders  to  appreciate  the  subtlety 
and  danger  of  attacks  on  computers  attached  to  open 
networks.  It  has  increased  public  appreciation  of  the 
dependence  of  important  segments  of  the  economv, 
aerospace  systems,  and  defense  networks  on  computers 
and  telecommunications.  Networks  of  computers  have 
joined  other  critical  networks  that  underpin  our  society — 
water,  gas,  electricity,  telephones,  air  traffic  control, 
banking,  to  name  a few.  just  as  we  have  worked  out 
ways  to  protect  and  ensure  general  respect  for  these 
other  critical  systems,  we  must  work  out  ways  to  pro- 
mote secure  functioning  of  networks  of  computers.  We 
cannot  separate  technology  from  responsible  use. 
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Secret  Codes 

Any  good  data  security  system  must  rely 
on  encryption 

Asael  Dror 


Cryptography  is  the 
ancient  art  of 
maxing  ’.he  com- 
prehensible in- 
comprehensible to  all  but  a 
chosen  few — of  keeping  se- 
crets secret.  Juiius  Caesar  :s 
creduea  with  protecting  the 
secrecy  of  messages  by  re- 
placing every  letter  in  the 
original  text,  caiiea  the  plain- 
text. with  a letter  three  char- 
acters later  in  the  alpnaoet. 

The  resuit  is  called  a cipner • 

'ex:,  in  which  .-1  is  represented 
by  D.  3 by  E.  ana  so  on. 

The  war  between  crvptog- 
raphers.  who  devise  crypto- 
systems. ana  coce  breaxers. 
who  try  to  decipner  encrypted 
messages,  has  drastically  es- 
calated since  the  invention  of 
the  comDuter  On  one  hand, 
computers  heip  to  oreax  com- 
plicated cr/ptosvstems  within 
seconds.  On  the  other  hand, 
they  make  it  feasible  to  use 
extremely  complex  encryption  algo- 
rithms that  were  not  practical  before. 
Furthermore,  the  advent  of  distributed 
computer  systems,  the  wide  avaiiaoiiitv 
of  microcomputers,  advances  in  mass 
storage,  and  tne  widespread  use  of  com- 
puter communications  have  all  contrib- 
uted to  moving  eryptogrnDnv  from  mili- 
tary and  diplomatic  fields  to  those  or 
more  general  interest  and  importance. 


Two  major  cryptosystems  are  in  use 
today:  conventional  systems  and  public  - 
kev  systems.  Two  maior  encryption  algo- 
rithms relate  to  these  cryptosystems: 
DES  and  RSA,  respectively 

Conventional  Cryptosystems 
One  important  method  of  encryption  is 
suosntution:  replacing  every  occurrence 
ot  a letter  (or  word,  or  byte)  with  a differ- 


ent letter  (or  word,  or  byte). 
The  XOR  operator  is  a conve- 
nient way  to  perform  substitu- 
tion with  computers.  When 
you  XOR  2 bits  togetner.  the 
resuit  is  1 if  one  ana  oniv  one 
of  the  input  bits  is  1.  The  re- 
suit  is  0 if  both  input  oits  are 
0.  or  if  both  incut  bus  are  1 . 

The  XOR  function  is  con- 
venient because  it's  fast  ana 
you  can  decrypt  the  encry  ptea 
information  simply  by  XOR- 
ing  the  ciphertext  with  the 
same  data  that  you  used  to  en- 
crypt the  piaintext.  For  exam- 
ple. you  can  encrypt  the  word 
TEST  by  XORmg  every  byte 
with  the  ASCII  representation 
of  the  letter  A (0100  0001).  In 
figure  la.  the  lener  A is  the 
kex  used  to  encrypt  the  plain- 
text. To  decrypt  tne  message, 
you  XOR  it  again  with  tne 
same  key,  as  in  tigure  lb. 

The  strength  of  a good 
cryptosystem  doesn't  depend 
on  keeping  its  algorithm  secret:  the  se- 
crecv  of  the  ciphertext  relies  soieiv  on  the 
secrecy  of  the  xev. 

A statistical  cryptoanalysis  attack  can 
easily  break  a simple  cryptosystem.  Nat- 
ural language  has  specific  known  pat- 
terns, suen  os  the  frequency  with  which 
each  letter  is  used;  common  letter  comoi- 
nations.  such  as  th.  er.  mg,  and  ion\  and 
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word-usage  frequency.  Those  plaintext 
patterns  will  also  appear— although  their 
expression  will  differ— m the  ciphertext: 
once  you  recognize  them,  you  can  use 
them  to  break  the  cipher.  Alternately, 
you  can  break  the  cryptosystem  with  a 
brute-force  attack.  Since  there  are  only 
256  possible  keys  (binary  0000  0000  to 
1 1 1 1 1 1 1 1),  a computer  can  quickly  try 
them  ail. 

One  way  to  overcome  these  problems 
is  to  use  longer  keys.  For  example,  you 
could  use  a four- “letter”  key  such  as 
A5GE  (a  good  “random”  key).  In  this 
case,  you  encrypt  the  first  byte  with  A. 
the  second  byte  with  5,  the  third  with  G. 
and  the  fourth  with  E.  After  exhausting 
the  key,  you  reuse  it:  so  you  encrypt  the 
fifth  byte  using  A again,  and  so  forth. 
The  key  length  is  4,  making  it  harder,  but 
not  impossible,  to  use  letter-pattern 
methods  to  break  the  code. 

Unfortunately,  if  code  breakers  know 
(or  can  guess)  part  of  the  piaintext  (e.g.. 
if  they  know  that  every  message  begins 
with  “Dear  Sir”),  then  they  can  use  ana- 
lytical cryptoanalysis  to  derive  the  key. 
In  figure  I,  XORing  the  plaintext  with 
the  ciphertext  reveals  the  key. 

Ideally,  you  should  have  a key  that 
never  repeats.  Such  a key.  composed  of 
random  aits  and  never  reused,  is  called  a 
one-ume  :ape  ior  one-ume pad).  You  can 
prove  mathematically  that  a cryptosys- 
tem based  on  a one-ume  tape  is  unbreak- 
able. Unfortunately,  such  a cryptosystem 
requires  a key  as  iong  as  the  message  you 
want  to  encrypt:  so  then  you  nave  to  fig- 
ure out  how  to  transmit  the  key  safely. 
Still,  one-time-cape  systems  are  usaole 
when  a safe  transDortation  means  is 


available  now  but  won't  be  m the  future, 
when  you  need  to  transmit  the  secret 
message. 

It  may  seem  that  you  could  create  a 
one-time-tape  cryptosystem  by  extending 
a short  key  with  a computer  s random- 
number-generating  function,  using  the 
short  key  as  the  seed.  Although  many 
commercially  available  data -encryption 
packages  use  such  a scheme,  it  snould  be 
considered  more  of  a toy  than  a crypto- 
system. A computer's  random-number 
generator  actually  generates  pseudo- 
random numbers.  A mathematical  rela- 
tionship exists  between  each  generated 
number  and  the  one  that  follows  it.  Con- 
sequently, such  proprietary  cryptosys- 
tems. often  described  as  unbreakable, 
can  usually  be  cracked  within  minutes 
(see  reference  l). 

DES 

Since  a layman  cannot  tell  the  difference 
between  a secure  cryptosystem  and  a 
complete  mockery,  the  National  Bureau 
of  Standards  (NBS)  established  the  Data 
Encryption  Standard  (DES).  It  was  origi- 
nally developed  by  IBM  and  adopted  as  a 
standard  by  the  NBS  in  1977.  In  1980.  it 
was  adopted  by  ANSI. 

Prior  to  becoming  a standard,  the  se- 
curity of  DES  was  validated  by  the  Na- 
tional Security  Agency  (NSA),  which 
found  the  algorithm  free  of  any  statistical 
or  mathematical  weaknesses  (see  refer- 
ence 21.  Since  :ts  adoption  as  a standard. 
DES  has  been  ased  by  most  bamcs  for 
money  transfers  and  by  most  U.S.  gov- 
ernment agencies  (except  the  military). 

DES  wonts  on  one  3-bvte  (64-bin 
block  at  a time.  The  encryption  process  is 


controlled  by  a user-supplied  56-bit  kev; 
that's  2’*  (72. 057. <94. 037. 927. 9um 
possible  keys.  Every  bit  in  the  output  is  a 
complex  function  of  every  bit  in  the  input 
block  and  every  bit  in  the  key  Decryp- 
tion under  DES  is  the  reverse  of  encryp- 
tion and  is  performed  by  working  the  al- 
gorithm backward.  The  encryption 
process  (see  figure  2)  consists  of  an  ini- 
tial permutation  of  the  input  block  fol- 
lowed by  16  rounds  of  encipherment,  and 
finally  an  inverse  of  the  initial  permu- 
tation. 

After  the  initial  permutation,  the 
block  being  encrypted  is  divided  into  two 
parts,  called  I_  and  R«,.  In  each  of  the  16 
rounds  of  encipherment  (see  figure  3). 
the  new  L part  is  the  previous  round's  R 
part.  The  new  R is  the  previous  round’s  L 
part  XORed  with  the  result  of  the  cipher- 
function/.  Thus,  the  output  of  round  i is 

L.  = R._, 

R.  = L.„  XOR  /( R,.„  K.) 

The  cipherfunction  / (see  figure  4)  de- 
rives its  output  based  on  the  old  R part 
(R ) and  the  current  round’s  key  (K,). 
You  use  the  inputs  to  perform  substitu- 
tion via  eight  lookup  tables  called  S 
boxes  and  then  permute  the  combined 
output  of  the  S boxes  to  give  the  func- 
tion's output. 

Each  round  uses  a different  -J-8-bit  key. 
K„  You  derive  the  current  round's  keys 
by  performing  a set  of  permutations  ana 
left  shifts  on  the  user-suopiiea  56-bit 
key  DES  defines  the  exact  left  shifts  ana 
permutations  used  to  derive  eac.n  rounc ' s 
key,  as  weil  as  the  definition  of  the  S 
boxes  and  ail  the  other  required  permuta- 
tions (see  reference  3). 

The  strength  of  DES  has  been  ascer- 
tained by  the  NSA's  thorougn  analysis 
and  years  of  widespread  use  without  any 
known  break  in  the  system,  DES’s  big- 
gest weakness  is  its  limited  key  lengtn. 
Its  critics  claim  that  you  might  be  abie  to 
break  DES  with  a brute-force  attack 
(i.e..  by  trying  every  possible  key). 

However,  trying  all  possible  keys 
within  a reasonaole  time  frame  wouid  re- 
quire a special  machine  that  would  use  as 
many  as  I million  processors  working 
concurrently.  Each  processor  would  de- 
crypt the  ciphertext  using  a different  set 
of  keys  and  check  (e.g..  by  using  a dictio- 
nary) to  see  if  it  had  guessed  the  correct 
kev  Even  though  it  would  cost  millions 
of  dollars  to  construct  such  a machine  (if 
at  ail  feasible),  the  fact  that  DES  is  in 
such  common  use  creates  an  incentive  to 
develop  it.  However,  this  theoretical 
shortcoming  is  no  reason  not  to  use  DES. 
[f  vou  are  worried  aoout  it.  vou  can  easily 


(a) 

Plaintext: 

(TEST) 

0101 

0100 

0100 

0101 

0101 

0011 

0101 

0100 

Key: 

(the  letter  A) 

0100 

0001 

0100 

0001 

0100 

0001 

0100 

0001 

Ciphertext: 

(plaintext  XOR  key) 

0001 

0101 

0000 

0100 

0001 

0010 

0001 

0101 

(b) 

Ciphertext: 

0001 

0101 

0000 

0100 

0001 

0010 

0001 

0101 

Key: 

(the  letter  4) 

0100 

0001 

0100 

0001 

0100 

0001 

0100 

0001 

Plaintext: 

(cipnertext  XCR  key) 

0101 

0100 

0100 

0101 

0101 

0011 

0101 

0100 

Figure  l:  A simple  example  of  (a)  encryption  and  (b)  decryption  usmq  the 
XOR  operator 
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Initial  permutation  . 
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16  1 1 
times;  Encpnerment  j 

-•-Key 

1 

j Inverse  mitiai 
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i 

f 

Cionerrext 

Figure  2:  The  DES  encryption  process. 
Every  bit  in  the  output  is  a complex 
function  of  every  bit  in  the  input  block 
and  every  bit  in  the  key. 

Figure  3:  The  details  that  are  involved  in  each  of  the  16  rounds  of  encipherment 
shown  in  figure  2.  Note  that  the  new  i part  is  the  R parr  from  the  previous  round, 
and  the  new  R is  the  L part  from  the  previous  round  XORed  with  the  result  of 
apherfunction  f. 


overcome  it  by  using  on  additional  pre- 
DES  encryption  stage. 

Public-Key  Cryptosystems 
When  using  a conventional  cryptosystem 
such  as  DES.  both  the  sender  and  the  re- 
ceiver must  know  the  key  used  to  encrypt 
(and  decrypt)  the  data.  Therefore,  you 
need  a safe  means  of  transmitting  the  key 
from  one  to  the  otner  If  you  change  the 
<eys  frequently,  transmitting  them  be- 
comes a major  proolem.  Furthermore, 
with  a conventional  cryptosystem,  it's 
impossible  to  communicate  with  some- 
one new  untii  _-ou  have  safety  exchanged 
keys:  this  car.  ta.se  a long  time  Puoiic- 
key  cryptosystems  are  designed  to  over- 
come these  snortcomings. 

Puoiic-key  cryptosystems  are  based  on 
the  ase  of  a trap-door  one-way  function. 
You  can  easily  compute  such  a function 
in  one  wav  only—  used  to  encrypt  the 
data.  To  compute  the  function  in  the 
other  direction— used  to  decrypt  the 
data— you  must  have  certain  secret  infor- 
mation: hence,  the  nam a trap-door 

In  a puolic-kcv  cryptosystem,  each 
person  has  two  keys:  one  for  encrypting. 
E . and  one  for  decrypting.  D,.  Decrypt- 
ing witn  D.  a plaintext  ? that  was  en- 
crypted using  E.  restores  the  original 
plaintext— that  is.  Df(E>vP^j  = ? Both 
E,  and  D . should  be  easy  to  compute,  but 
knowing  E,  does  not  reveal  Dv. 

If  you  use  a puoiic-key  cryptosystem, 
you  can  puolish  your  encrypting  key  E 
(the  puolic  kevi  in  a puoiie  directory, 
while  you  keep  D (the  private  key) 
secret  If  someone  wants  to  send  you  a 
message,  all  that  person  has  to  do  is  loo* 
up  your  puolic  key  iEj  and  use  it  to  en- 
crypt the  message  as  E,(Pl.  Only  you 

continued 
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Fiuure  4:  Clpherfunctton  f from  figure  3.  Its  output  comes  from  the  old  R parr 
(R  J and  the  current  kev  >K  ).  The  inputs  use  etyht  S boxes  to  perform  substitution 
and  then  permute  their  comnined  output  to  ipve  the  function  s out  pm 
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know  the  private  key  Dv,  so  only  you  can 
decrypt  the  message  back  to  its  original 
plaintext,  D4(EV(P))  = P 

RSA 

The  most  important  public-key  crypto- 
system today  is  RSA  (see  reference  4), 
named  after  its  inventors,  Rivest.  Sha- 
mir, and  Adleman.  To  use  RSA,  you 
need  to  choose,  at  random,  two  large 
prime  numbers,  to  be  called  p and  q. 
Compute  n as  the  product  of  the  two 
primes:  n—p*q.  Then,  randomly  choose 
a large  number  d,  so  that  d is  relatively 
prime  to  (p  — l)»(<y—  1);  in  other  words, 
the  greatest  common  divisor  of  d and 
(p- 1)  is  l.  Finally,  compute  <?  so 
that  (e«<i)  modulo  ((p- 1))  = 1. 
The  notation  "x  modulo  y”  signifies  the 
remainder  of  dividing  x by  y using  inte- 
ger division.  For  example.  20  modulo  5 
= 0,  since  20/5  - 4 with  0 remainder: 
13  modulo  3 = l since  13/3  = 4 with  l 
remainder. 

The  public  key  is  the  pair  of  numbers 
(e.n),  and  the  pnvate  key  is  (d.n).  Al- 
though n and  e are  public,  it  is  difficult  to 
amve  at  d.  since  there  is  no  efficient  al- 
gorithm for  factoring  large  numbers. 
Consequently,  to  be  secure,  both  p and  a 
must  be  very  large  (at  least  100-digit 
numoers).  so  that  n is  extremely  large  tat 
least  200  digits)  and  cannot  be  factored 
within  a reasonaoie  time. 

To  encrypt  with  RSA,  first  you  break 
the  plaintext  into  blocks  that  can  oe  rep- 
resentea  as  an  integer  between  0 ana 
n — 1.  Then,  you  encrypt  eacn  clock  by 
raising  it  to  the  power  <?.  modulo  n.  To 
decrypt  the  block,  raise  it  to  the  power  d. 
moduio  n:  that  is.  C =P*  moduio  n , and 
P = C*  moduio  n. 

Lets  look  at  an  example  of  how  to  use 
RSA.  For  the  sake  of  simDiicitv,  you 
snouid  use  very  small  primes  for  p and  q. 
To  create  a secure  system,  however,  you 
should  use  very  large  primes  (to  find 
large  prime  numbers,  see  reference  5). 

• Assume  vou  choose  p = 3 ana 

<7=11- 

• Then,  n =p«q  = 3 • i 1 = 33  and 
(p-l)-<q-  1)  = 2m0  = 20. 

• You  can  use  d = 7,  since  7 is 
relatively  prime  to  20. 

• Next,  you  need  to  find  an  e.  so  that 
e*7  modulo  20  = 1 . 

• You  can  use  e = 3 because  3 • 7 = 21. 
and  2 1 modulo  20  = 1. 

• Thus,  your  puolic  kev  is  13.33)  and 
your  private  key  is  (7,33). 

[f  you  represent  your  message  by  using  a 
1 for  ,4,  2 tor  3.  3 for  C.  and  \o  on.  the 
plaintext  DEAD  would  be  written  as  4 5 


l 4 The  following  table  shows  how  to  en- 
crypt this  using  the  public  key  (3.33). 


P 

P* 

P*  modulo  n 

4 

64 

31 

5 

125 

26 

l 

I 

l 

4 

64 

31 

Thus,  the  ciphertext  is  31  26  l 31  (using 
large  primes  would  let  you  create  large 
blocks  that  would  conceal  the  patterns 
detectable  in  this  simplified  example). 

To  decrypt  this,  you  would  use  the  fol- 
lowing to  restore  the  original  plaintext, 

C C4  C4  modulo  n 


31 

275126141 l l 

4 

26 

8031810176 

5 

1 

1 

1 

31 

275126141 1 1 

4 

The  RSA  algorithm  has  been  known 
since  1978,  and  in  no  known  case  has  it 
been  broken.  Its  strength  is  based  on  the 
complexity  of  factoring  very  large  num- 
bers. However,  while  no  algorithm  has 
yet  been  found  to  efficiently  factor  large 
numoers.  such  an  algorithm  may  exist.  If 
such  an  algorithm  is  found.  RSA  wouid 
be  rendered  useiess.  Furthermore,  no 
one  has  proven  that  factoring  n is  essen- 
tial to  deriving  the  pnvate  key. 

On  a more  practical  note.  RSA’s  oper- 
ations on  very  large  numoers  make  the 
system  extremeiv  siow  In  addition,  the 
RSA  algorithm  is  patented,  and  you  can't 
use  it  freely. 

Digital  Signatures 

In  addition  to  ensunng  privacy,  encryp- 
tion can  be  used  to  verify  authenticity 
Say  you  send  your  broker  a message  tell- 
ing him  to  sell  all  your  stocks.  How  can 
the  oroker  verify  that  you  sent  it?  If  you 
dispute  ever  sending  the  message,  how 
can  the  broker  prove  that  you  did?  If  you 
used  oaper  mail,  your  signature  would  be 
used  to  verify  and  prove  authenticity,  but 
how  aoout  electronic  messages? 

Simpiv  encrypting  the  message  using  a 
key  known  only  to  you  and  the  broker 
doesn't  solve  the  problem.  The  broker 
wouid  be  satisfied  that  you  had  sent  the 
message,  but  couldn't  prove  it  since  he 
know?  the  key  and  thus  could  have  forged 
the  message.  Puolic-key  cryptosystems 
can  provide  an  elegant  and  simple  solu- 
tion by  creating  digital  signatures. 

A trap-door  one-way  function  has  the 
property  of  D(E(P))  = P If  the  function 
used  by  the  pubhc-kev  crvptosvstem  also 
has  the  property  of  El  D(  P))  = P,  it  is  said 
to  be  a trap-door  one-*ax  permutation. 
The  RSA  public-kev  cryptosystem  ful- 


fills this  requirement.  Using  such  a puo- 
lic-kev  cryptosystem,  you  can  encrypt 
the  message  using  the  private  key  D, 
Anyone  wno  receives  the  message  D,(P) 
can  decrypt  it  using  your  public  key 
since  EjDvtP))  = P Since  D,  is  known 
only  to  you,  the  recipient  knows,  and  can 
prove,  that  you  are  the  author. 

If  you  want  to  send  a private  message 
that  can  be  authenticated  to  someone 
eise.  then  you  encrypt  DV(P)  with  that 
person's  public  key,  giving  E,(D,(P)). 
Using  the  private  key.  D,,  that  person 
would  derive  Ds(E,(Dt(P)))  = D,(P), 
which  would  be  saved  as  proof  of  authen- 
ticity. and  then  decrypt  D,(P)  by  using 
Et(D*(P))  = P.  Thus,  both  privacy  and 
authenticity  have  been  achieved. 

Secure  Computer  Systems 
Any  good  computer  data  security  system 
must  rely  on  encryption.  Whereas  both 
DES  and  RSA  provide  a good  basis  for  a 
computer  security  system,  using  propri- 
etary algorithms  may  be  worse  than 
using  no  encryption  at  ail.  because  they 
lead  to  a false  sense  of  security. 

But  encryption  alone  is  not  sufficient. 
Proper  key  selection,  key  management, 
physical  security,  people  security,  ana 
procedures  to  ensure  that  plaintext  does 
not  '‘leak"  out  of  the  system  via  iooo- 
hoies  (see  reference  6)  are  ail  essential 
for  a secure  computer  data  system.  ■ 
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This  reading  list  is  the  product  of  the  Information  Exchange  Working  Group  of  the 
Cmputer  and  Telecommunications  Security  Council,  a govemment/industry  technical  group 
that  was  sponsored  by  NIST  from  1987  to  1990.  The  entries  provide  titles,  sources,  and 
reviews  of  important  publications. 


Bugs  in  the  Program : Problems  in  Federal  Government  Computer  Software 
Development  and  Regulation . Staff  study  by  the  Subcommittee  on  Investigations  and 
Oversight,  Committee  on  Science,  Space,  and  Technology,  U.S.  House  of 
Representatives.  August  3,  1989.  35  pages. 

This  report  is  useful  because  of  the  many  useful  references  cited  and  the  short,  emphatic  quotes  that  are 
effecuve  in  presentations  on  the  need  for  a formal  role  to  be  played  by  information  security  specialists  in  the 
software  development  and  acquisition  process. 

The  detailed  report  comes  from  a study  of  current  literature,  cases  of  software  failure,  and  interviews  of  over 
50  experts  including  Dr.  Peter  Neumann  from  SRL  It  documents  the  disastrous  state  of  software  quality  and 
reliability  including  security.  Software  development  methods  are  described  including  the  failure  of  the 
waterfall  method  of  user  requirements  specification  followed  by  implementation.  The  need  for  an  iterative 
process,  e.g.,  Boehm’s  Spiral  method,  is  emphasized  along  with  recognizing  problems  of  costing  this 
approach.  Major  software  disasters  are  cited. 

A good  presentation  on  the  need  for  security  in  the  products  and  development  efforts  is  made  but  no 
solutions  are  offered.  Ethics  and  certification  of  programmers  are  also  discussed.  Further  study  of  the 
problem  is  recommended. 

The  Cuckoo's  Egg , by  Clifford  Stoll.  Doubleday  1989.  326  pages. 

This  is  a personnel  history  of  the  life  of  a computer  system  manager  during  an  18-month  siege  by  a 
malicious  hacker.  It  is  not  a technical  treatment.  (See  Dr.  Stoll’s  ACM  Communications  article  May,  1988 
for  a technical  approach.)  The  title  derives  from  the  Cuckoo  bird’s  practice  of  putting  its  eggs  in  other  birds 
nests  to  hatch.  The  book’s  most  interesting  story  describes  the  metamorphosis  of  a 1960s  Berkeley  activist  to 
a responsible  adult  with  respect  for  law  and  order.  The  book’s  strong  message  is  the  need  to  reject  and  eject 
malicious  hackers  from  the  community  of  computer  network  users.  Chapter  55  is  a good  case  study  of  the 
German  hackers  who  worked  for  the  KGB.  Otherwise,  the  book  makes  light  and  enjoyable  reading. 

Final  Report  on  Computer-Related  Crime , Council  of  Europe,  Publications  Division, 
Strasbourg,  France  or  Manhattan  Publishing  Co.,  P.O.  Box  659,  Croton,  New  York 
10520.  1989.  82  pages. 

Robert  E.  Smith  (Privacy  Journal)  reports  this  document  as  one  of  the  most  methodical  and  useful  studies  of 
legal  issues  in  computer  crime.  It  contains  guidelines  for  national  legislation  on  computer  crime  as  well  as 
evidenuary,  procedural,  and  other  problems  of  transnational  offenses. 


Computer  Crime:  Criminal  Justice  Resource  Manual , Second  Edition,  by  Donn  B. 
Parker.  NCJ  118214  (National  Institute  of  Justice,  800-851-3420,  P.O.  Box  6000, 
Rockville,  MD  20850).  1989.  220  pages. 

This  manual,  a rewritten  edition  of  the  original  manual  published  in  1978,  is  written  for  investigators  and 
prosecutors  of  computer  crime  in  the  U.S.  However,  it  provides  insights  on  this  subject  important  for 
information  security  specialists.  In  particular,  advice  is  provided  on  the  requirements  for  security  detection 
controls  to  produce  information  acceptable  as  criminal  evidence.  Analyses  of  federal  and  several  state 
computer  crime  statutes  are  included. 

Organizing  for  Computer  Crime  Investigation  and  Prosecution , by  Catherine  H.  Conlv. 
NCJ  118216.  National  Institute  of  Justice.  1989.  124  pages. 

Dedicated  Computer  Crime  Units , by  J.  Thomas  McEwen.  NCJ  118215.  National 
Institute  of  Justice.  1989.  129  pages. 

Information  Technology  Installation  Security,  Federal  Systems  Integration  and 
Management  Center,  Office  of  Technical  Assistance,  5203  Leesburg  Pike,  Suite  400, 
Falls  Church,  VA  22051.  December  1988.  98  pages. 

This  publication  addresses  all  government  managers  having  responsibility  for  information  technology.  The 
publication  is  intended  to  assist  them  in  developing,  implemendng,  and  maintaining  security  policies, 
procedures  and  techniques. 

Computer  Viruses:  Dealing  with  Electronic  Vandalism  and  Programmed  Threats , by 
Eugene  Spafford,  Kathleen  Heaphy  and  David  Ferbrache.  ADAPSO,  1300  North 
Seventeenth  Street,  Suite  300,  Arlington,  VA  22209.  1989.  109  pages. 

This  book  presents  a high-level  discussion  of  computer  viruses,  explaining  how  they  work,  who  writes  them, 
and  what  they  do.  It  is  not  a technical  reference  on  viruses.  The  book  dispels  common  myths  about  viruses 
and  provides  simple,  effective  suggestions  on  how  to  protect  computer  systems  against  threats. 

Managing  Information  Resources:  New  Directions  In  State  Government , Dr.  Sharon  L. 
Caudel,  Dr.  Donald  A.  Marchand  with  Dr.  Stuart  L Bretschneider,  Ms.  Particia  T. 
Fletcher,  and  Mr.  Kurt  M.  Thurmaier.  School  of  Information  Studies,  Syracuse 
University,  4-206  Center  for  Science  and  Technology,  Syracuse,  NY  13244-4100. 
August,  1989.  307  pages. 

This  report  is  a joint  effort  between  the  National  Association  for  State  Information  Systems,  Inc.,  information 
processing  industry  companies,  and  Syracuse  University’s  School  of  Information  Studies  which  directed  the 
research.  The  principal  objectives  of  the  study  were  to  inventory  and  analyze  the  management  policies  and 
practices  applied  to  information  and  information  technology  in  state  governments  and  to  share  those 
approaches. 

Security  in  Open  Systems:  A Security  Framework  (ECMA  TRI46),  European  Computer 
Manufacturers  Association,  114  Rue  du  Rhone,  1204  Geneva,  Switzerland.  July  1988. 
71  pages. 

This  technical  report  provides  a framework  for  the  development  of  standards  that  support  a wide  variety  of 
security  requirements  in  a multi-user,  multi-vendor  systems  environment.  The  report  gives  an  overview  of 
security  requirements  from  both  the  operational  and  the  functional  point  of  view.  It  also  gives 
implementation  considerauons  and  design  requirements  relevant  to  the  design  of  secure  systems  on  the  basis 
of  this  framework. 


Security  in  Open  Systems  Data  Elements  and  Service  Definitions  (Alice  in  Wonderland ), 
European  Computer  Manufacturers  Association,  114  Rue  du  Rhone,  1204  Geneva, 
Switzerland.  July  1989.  74  pages. 

This  ECMA  Standard  defines  data  elements  and  services  for  the  support  of  a wide  variety  of  security 
requirements  in  a multi-user,  multi-vendor  distributed  system  environment..  The  data  elements  and  services 
developed  in  this  standard  are  based  on  concepts  defined  in  ECMAyTR46:  "Security  in  Open  Systems  - A 
Security  Framework." 

DOE  Risk  Assessment  Instructions , Resource  Tables , and  Completed  Sample  — A 
Structured  Approach,  Department  of  Energy’s  Office  of  ADP  Management  and  the 
Computer  and  Technical  Security  Branch  (Raymond  Barrow  301-353“3307).  Two 
volumes  and  one  diskette.  September  1989. 

The  guideline  presents  a simplified,  structured  approach  to  the  risk  assessment  process.  When  completed,  the 
risk  assessment  results  produce  an  Executive  Summary  which  provides  a mechanism  for  briefing,  reviewing, 
and  discussing  the  identified  risks  with  upper  management  and  assists  with  the  identification  of  resources 
needed  to  implement  appropriate  countermeasures. 

Some  Technical  Security  Hazards  Associated  with  Copier  and  Printer  Technologies , 
Defense  Copier  Security  Working  Group  of  the  Defense  Information  Security 
Committee.  November  6,  1989.  9 pages. 

This  report  highlights  and  discusses  several  technical  security  hazards  identified  during  the  work  of  the 
Defense  Copier  Security  Working  Group  of  the  Defense  Information  Security  Committee.  The  hazards  exist 
in  printers  used  as  automated  information  system  hard  copy  output  devices  as  well  as  in  copiers.  The  report 
is  not  all  inclusive;  it  focuses  primarily  on  copier  security  procedures  and  some  limited,  basic  security  features 
that  support  them.  The  report  does  address  the  major  security  hazards  inherent  in  this  equipment 

Guide  for  Selecting  Automated  Risk  Analysis  Tools  ( Special  Publication  500-174 ),  Irene 
Gilbert.  National  Institute  of  Standards  and  Technology.  October  1989.  26  pages. 

This  document  recommends  a process  for  selecting  automated  nsk  analysis  tools.  It  is  intended  primarily  for 
managers  and  those  responsible  for  managing  risks  in  computer  and  telecommunications  systems.  The 
document  describes  important  considerations  for  developing  selection  criteria  for  acquiring  risk  analysis 
software.  The  information  presented  is  derived  from  reviews  of  risk  analysis  software  tools  in  the  Risk 
Management  Laboratory  which  is  cooperatively  sponsored  by  the  National  Institute  of  Standards  and 
Technology  and  the  National  Computer  Security  Center  and  from  experiences  of  organizations  in  the  federal 
government  and  private  sectors. 

Computer  Security  Training  Guidelines  ( Special  Publication  500-172 ),  Mary  Anne  Todd 
and  Constance  Guitian.  National  Institute  of  Standards  and  Technology.  November 
1989.  32  pages. 

This  document  provides  a framework  for  identifying  computer  security  training  requirements  for  a diversity  of 
audiences  who  should  receive  some  form  of  computer  security  training.  It  focuses  on  learning  objectives 
based  upon  what  computer  security  knowledge  is  required  by  an  individual  in  their  job.  The  guide  divides 
employees  involved  in  the  management,  operation,  and  use  of  computer  systems  into  five  audience  categories. 
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Executive  Guide  To  The  Protection  Of  Information  Resources  ( Special  Publication 
500-169 ),  Cheryl  Helsing,  Marianne  Swanson,  Mary  Anne  Todd.  National  Institute  of 
Standards  and  Technology.  October  1989.  14  pages. 

This  guide  is  designed  to  help  the  policy  maker  address  a host  of  questions  regarding  the  protection  and 
safety  of  agency  computer  systems  and  data  processed.  It  introduces  information  systems  security  concerns, 
outlines  the  management  issues  that  must  be  addressed  by  agency  policies  and  programs,  and  describes 
essential  components  of  an  effective  implementation  process. 

Management  Guide  To  The  Protection  Of  Information  Resources  ( Special  Publication 
500-170),  Cheryl  Helsing,  Marianne  Swanson,  Mary  Anne  Todd.  National  Institute  of 
Standards  and  Technology.  October  1989.  14  pages. 

This  guide  describes  the  issues  that  must  be  addressed  by  agency  managers  in  meeting  their  responsibilities  to 
protect  information  resources  within  their  organizations.  It  outlines  the  critical  elements  of  an  information 
resource  protection  process  that  applies  to  a stand-alone  personal  computer  or  to  a large  data  processing 
facility. 

Computer  Userys  Guide  To  The  Protection  Of  Information  Resources  Special  Publication 
500-171),  Cheryl  Helsing,  Marianne  Swanson,  Mary  Anne  Todd.  National  Institute  of 
Standards  and  Technology.  October  1989.  12  pages. 

This  guide  makes  the  computer  user  aware  of  some  of  the  undesirable  things  that  can  happen  to  data.  It 
provides  practical  solutions  for  reducing  the  risks  to  such  threats  as  unauthorized  modification,  disclosure,  and 
destruction,  either  deliberate  or  accidental. 

Data  Encryption  Standard  Fact  Sheet,  Computer  Security  Division,  National  Institute 
of  Standards  and  Technology,  (301)  975-2934.  January  1990.  9 pages. 

This  document  addresses  those  frequently  asked  questions  regarding  various  aspects  of  the  Data  Encryption 
Standard  (DES).  It  provides  interested  individuals  with  sources  of  additional  information.  The  document 
does  not  issue  new  policy;  rather  it  summarizes  and  clarifies  existing  policies. 

Computers  under  Attack:  Intruders,  Worms,  and  Viruses,  Peter  Denning,  Editor,  ACM 
Press,  1990.  Order  Number  706900.  $17.50.  150  pages  in  paperback.  (ACM  Press, 
11  West  42nd  Street,  New  York,  NY  10036.  Tel  (212)  869-7440,  fax  (212)  944-1318). 

From  the  advertisement:  "A  collection  of  some  of  the  most  informative,  provocative,  and  frightening  reports 
on  the  vulnerability  of  computer  systems  to  harmful,  if  not  catastrophic,  attacks.  Denning  is  editor-in  chief  of 
Communications  of  the  ACM  and  is  Director  of  the  Research  Institute  for  Advanced  Computer  Science, 
NASA-Ames  Research  Center. 

Spectacular  Computer  Crimes , Buck  Bloombecker.  Dow  Jones  Irwin,  Homewood,  IL 
60430.  242  pages. 

This  is  an  interesung  book  that  expresses  the  unusual  legal  ideas  of  the  author  about  famous  computer  crimes. 
The  use  of  real  names  of  victims  and  perpetrators  in  several  of  the  very  old,  settled  cases  described  does  a 
disservice  to  those  people  and  organizations  who  should  have  the  right  to  outlive  those  painful  experiences. 


Commitment  To  Security , National  Center  for  Computer  Crime  Data,  (NCCCD,  904 
Daniel  Court,  Santa  Cruz,  CA  95062)  1989. 

This  report  was  sponsored  by  ISSA  and  several  companies  by  the  not-for-profit  NCCCD  and  is  the  product  of 
JJ.  Buck  Bloombecker  and  Dr.  Stanley  Stahl.  Copies  were  sent  to  all  ISSA  members  free  of  charge.  It 
contains  the  best  and  worst  of  statistics  about  information  security. 

Disaster  Recovery  Journal , Richard  L.  Arnold,  publisher,  2712  Meramar  Drive,  St. 
Louis,  MO  63129. 

Contingency  Journal , Bob  Thomas,  publisher,  10935  Estate  Lane,  Suite  375,  Dallas, 

TX  75238. 

Crisis  Magazine , Robert  J.  Bogle,  publisher,  190  South  Warner  Road,  Suite  100, 
Wayne,  PA  19087. 

These  are  three  new  trade  journals  in  the  disaster  recovery  and  contingency  planning  field  that  has  become  a 
specialty  field  in  its  own  right 

Systems  Auditability  and  Control  Reports , Institute  of  Internal  Auditors,  249  Maitland 
Ave.,  Altamonte  Springs,  FL  32701.  Future  publication. 

In  February  1990$  the  Institute  of  Internal  Auditors’  Research  Foundation  (II A)  began  a year-long 
comprehensive  revision  of  the  definitive  Systems  Auditability  and  Control  (SAC)  Reports  that  it  published  in 
1977.  The  original  report  resulted  from  a study  undertaken  for  the  Foundation  by  SRI  International.  The 
revision  is  under  the  direction  of  Price- Waterhouse  and  is  expected  to  be  completed  in  mid- 1991.  The  project 
is  expected  to  cost  more  than  SI. 25  million.  $500,000  has  already  been  obtained  from  IBM.  IIA  plans  call 
for  expanding  the  three  volumes  of  the  earlier  SAC  edition  into  10  modules  and  for  supplementing  these  with 
seminars  and  video-based  training  materials. 
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